Gentle overview of the core ideas exploited by the Spectre and Meltdown CPU attacks, including speculative execution, side-channel attacks, and cache memory. Presented by Prof. Ymir Vigfusson at Emory University (ymsir.com).
This is the most relaxed and best explanation of the topic I have found on the whole internet. You do not only make good examples, but you also slowly approach the topic with analogies and good visual representation. It is nearly perfect, the only thing worth improving is your microphone. Kudos to this. You should be a teacher.
One of the most visually delighing and comprehendible explanations. Please note 14:29 mins is the crux of the explanation where usgae of an instrument, side channnel timing attack , memory leakage and other concepts comverge
In your example, how can a process controlled by the attacker access the memory allocated to a victim? Each process gets its own virtual address space. However, it does make sense that an attacker process could access kernel memory through speculative execution, bypassing privilege checks, thus melting the boundary between kernel and user process memory, hence the name "meltdown". The example you gave is more representative of the Meltdown vulnerability than Spectre, and a good mitigation for the Meltdown vulnerability would be kernel page table isolation. Spectre is based on the attacker training the CPU's branch predictor to expect certain branches and the cache implementation.
Great video , I really like how you abstract things and make it simple to understand. I came to this video to understand what a meltdown attack is and you really nailed it. Bravo! [Constructive] Regarding the audio, many times It was a bit hard for me to understand your words, that made me repetitively go back and listen over and over again. I think It's a combination of your non-native accent and the low quality of the sound. I think that either using a higher bit rate for the sound or attaching subtitles (or both) would make it less struggling for me. Could be my ears only , though :)
These are security issues and have Not yet been seen and publicly documented outside a lab. Though i still want the cpus designed to prevent this from happening
Can anyone explain how accessing Instrument[A[x]] results in the number 4 being "played"? I didn't really understand the syntax of "access Instrument[A[x]]". Thank you so much!
cache memory explanation is horrendously terrible... you should always show the cpu when talking about cache memory. the only reason why its called cache memory is because of latency, the cache memory block is literally inside the cpu and close by to the ALU, this makes it ridiculously fast for the cpu to load cache memory compared to ram memory. after ur cache explanation i had to force myself to watch another person describing about the spectre attack... and no it's not slow like a turtle, this is gunna make people dumb and think computers are slow. its just "slighty" slow compared to cache memory, not a full blown one second, minute or hour. We are talking about "slow" in the sub milli/micro/nano seconds, not a legit turtle speed..
Thanks for your comment -- I'll respond since I believe it is misleading. I am speaking of _relative_ speeds, which is an intuitive way of explaining time scales (or any scale) beyond what we experience normally as humans. Also, while the built-in cache memories are on the CPU, they are not inside the CPU _core_ that's doing the executions. And finally, at a relative level, an average instruction of a CPU core operating at only 1GHz is around 1ns, whereas accessing L3 on-chip is 20ns, or 20x slower. DRAM, at 80-100 ns is thus 80-100x slower than the execution of a single instruction (even those involving registers which are effectively the fastest form of memory in a modern computer). Thus I argue that the analogy is not actually misleading --- in fact, I wish more people deployed them to better understand the very basics of why poorly architected software perpetually winds up being slow!
@@YmirVigfussonPresents I clearly know the difference between the terms of cpu core and cpu. All of the most best explanations in books, articles and RU-vid related to cpu always shows the cache memory inside the cpu (not cpu core). This is the main reason why cpu core has fast access to cache memory as compared to external memory such ram. Many people does not know this and it brings confusion, stating that the cache memory is located inside the cpu (not cpu core) will make things much more sense.
I have paused, after a few seconds you were telling us about a series of attacks we have seen lately. What attacks? Do you know someone who has been attacked?
I understand this might be just an example, but being regular string password "hunter2" is stored in memory sequentially and when CPU loads first symbol, following (let's say 64) will appear in CPU cache as part of the same cache-line, so why should CPU spend more time on the next symbol reading?
You are right on both accounts: it's just an example, and indeed memory accesses like that have an interplay with the cache hierarchy and register sizes. It's worth looking at academic papers or implementations of timing attacks, precisely to see how to control for these effects.
Can anyone tell me why A[x] doesn't throw an Out of Bounds exception? This attack kind of makes use of a buffer overread... And there are already defences in place for such attacks, right? Then how does A[x](a buffer overread go through)?
The CPU does this speculative. The IF instruction is not yet completed at this point and the CPU is already starting to process the instructions contained in the IF loop speculative in order to be able to provide an answer more quickly if the IF query as to whether the earth is flat is correct. In the normal flow of the program, the question whether the earth is flat is of course answered with no. Which is why the IF loop would not be entered in normal program flow. But since it was already entered in advance and speculatively, an out of bounds error was never thrown here, because that was not the normal program flow, but only a speculative one that was not checked. And since this was done speculatively, the data is now in the cache. It's a quite clever attack.
Professor. I have been spending an entire week trying to rid myself of this very attack you are describing. It has infected everything survived hard drive wipes affected windows and Ubuntu. And I think I am in over my head. I would be willing to compensate you for your time should you be able to chat with me for a few minutes I am in need of someone who has experience with this. It's driving me insane.
