Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

Things you must know before you can understand Meltdown:

* The memory hierarchy (registers, cache, memory); really all programmers always need to know the memory hierarchy and Meltdown just sort of reinforces that.

* The basics of kernel memory management (kernel memory is mapped into userland processes and protected by page table permissions checks).

* Very basic assembly language (basically what a variable assignment and an "if" statement compile down to).

* The idea of pipelined CPUs, the idea that on modern CPUs the registers you see in assembly instructions are actually renamed from a larger invisible register file, and the distinction between instruction execution and retirement.

If you've got this I think you can just read the paper: https://meltdownattack.com/meltdown.pdf. It's really well written. In particular: I don't think you need to understand much about timing attacks. The Flush+Reload paper (you can just Google it, it'll be the first result) is also really well written, but you'll be fine in the Meltdown paper without having read it.

I tried reading the flush+reload paper several times, and watching a couple of the author's talks on it as well. I still haven't come out with a halfway decent understanding of how the timing attack works...which seems to be the most difficult and interesting part to me. It seems like its well understood in the security community, so it gets glossed over when referenced. How they actually manage to read data out of an evicted cache line remains a mystery to me.

Is it the timing mechanism you have trouble with, or the timing target? Flush+Reload is (to me) an unusually clear paper (it's an engineering paper, which is probably why it wound up at Usenix). But even in the paper, the actual target (not just understanding square-and-multiply but also how that gets translated into cache hits) is tricky.

The nice thing about Meltdown and Spectre is that the cache hits are less tricky to understand; they're engineered specifically to make the exploit work.

[I had to go back and reread it a couple of times...naturally :)]

I guess part of what bothered me is what makes it well written; there is so much of the discussion spent on background, which felt like stating the obvious to me. It wasn't clear to me how specific the conditions needed to be for the attack. They use GnuPG as an example, and ostensibly rely on knowing the algorithms that the decryption and encryption functions beforehand. With knowledge of the implementation, they're able to trace execution, and subsequently infer each bit of the victim data that they want to probe. They also need to know the victim's cache characteristics; hierarchy and timing.

It's a far cry from arbitrarily reading memory on an arbitrary victim.

They're not reading data out of the cache line. Often the contents of the cache are public anyway.

What they're detecting is whether a piece of memory is in the cache or not. This lets them infer the contents of some other piece of memory.

For example, an if-statement might check whether or not a secret bit is set, and that might lead the process to call function A or function B. By detecting whether it's A or B that lands in the instruction cache, you can infer the value of the secret bit.

Reply on news.ycombinator.com