5 ms·

Tried to write a meltdown explanation for "everyday" developers. There are some loose analogies and inexact writing. (Please point out mistakes, they're mine)

rocqua 9y ago
I think the specter paper stated that the CPU doesn't run both branches at the same time. Instead it picks one based on speculation and runs that branch. If it picked wrong it rolls back and only then does it start running the other branch. The article states different. If I'm right that would also require some specter-like attack to make sure the desired branch is actually executed speculatively. Alternatively, maybe you can catch the exception and use that to indicate the desired branch was run.
- scott_s 9y ago
  You're correct that's how speculative execution works: it picks one branch, it does not pick both branches. But that's the Spectre vulnerability, while this article is trying to explain Meltdown, and Meltdown does not involve speculative execution. (See my other comment in this thread for a full explanation.)
  - rocqua 9y ago
    Thanks, you comment was really clear :)
DiffEq 9y ago
How easy or how likely is a meltdown attack likely to be successful against a moderately protected PC or say a VMware Cluster...these kinds of things seem hard to pin down...and if all one can do is READ - exactly what is to gain here? It seems that the machine would have already had to have been compromised in another way to get the memory that has been READ off and out of the computer system.
- captn3m0 9y ago
  There are known PoCs for Meltdown using JS, which is what made this so scary. Heartbleed was far worse in comparison since it was remotely exploitable. But the JS vectors for Meltdown make it scary.
  - jnordwick 9y ago
    Where? We've been told it is possible, but I have yet to see a JavaScript exploit that wasn't basically a canned demo.
    - unclepresent 9y ago
      I doubt it is possible to be done on JavaScript. Timing cache access is a challenging task for such high level language. The key to the attack is to figure out latency of memory access. A JavaScript app that is dealing with 100 layers of intermediate code before it actually gets to the physical memory could not see a difference between reading from actual memory or from cache. It is too slow to notice any change. Should be a pure assembler code to reliably estimate the effect of caching.
      - jnordwick 9y ago
        If you are already running untrusted binaries, there are bigger issues. Without a JS exploit, I'm not sure this is a big problem. And we haven't seen a real world binary version either. The versions I've seen all take running starts so to speak.
- bennofs 9y ago
  The problem is that it bypasses sandboxes and isolation features... normally, JavaScript running in a VM in a sandbox in your browser cannot read all of your memory. With meltdown, that could be possible. Although for that scenario, you need to combine Meltdown with Spectre variant 1, allowing you to read arbitrary kernel memory from JavaScript in a browser.
- willvarfar 9y ago
bitexploder 9y ago
Nice write up. One of our guys wrote a similar piece. https://www.carvesystems.com/blog/meltdown-spectre.html https://www.carvesystems.com/blog/meltdown-spectre.html One of the biggest challenges describing low level systems vulnerabilites like these is you have to actually learn at least a little about the CPU internals and high level explanation only gets you so far. I think adding a "why this matters" to your post is helpful.
- captn3m0 9y ago
  This is helpful, thanks. I'll update this post with your recommendation. Planning to read the Spectre paper next week and do another blog post. Edit: Just read your blog post, definitely need to add a "what's this about", and a "what you should do" section.
ikeboy 9y ago
The first section on cache timing seems off. "The one which is being read is cached, and the exception will be raised much faster as a result." I only read the project zero post, not the paper, but I don't recall it having anything to do with timing of exceptions. I don't see the point or relevance of this section. Might be missing something. Edit: mixed up Meltdown with Spectre, I'll take a closer look at this later
- kahnjw 9y ago
  The attack relies on side channel attacks, specifically Flush+Reload, which uses timing to find accessed memory locations in another program, as stated in both the paper and this summary. It is definitely relevant.
  - deleted 9y ago
    [deleted]
- captn3m0 9y ago
  The "flush+reload" mentioned in the Project Zero blog[0] is a variant of cache-timing attacks. The original Flush+reload paper has more details[1], but I intentionally didn't delve into the specifics of Flush+Reload. The description I've used is more closer to Evict+Time actually. If you're interested, I recommend this presentation[2] for more details on the category of attacks. [0]: https://googleprojectzero.blogspot.in/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.in/2018/01/reading-privil... [1]: https://eprint.iacr.org/2013/448.pdf https://eprint.iacr.org/2013/448.pdf [2]: https://conference.hitb.org/hitbsecconf2016ams/materials/D2T1%20-%20Anders%20Fogh%20-%20Cache%20Side%20Channel%20Attacks.pdf https://conference.hitb.org/hitbsecconf2016ams/materials/D2T... (Youtube: https://youtu.be/UH6dFbiX_hM https://youtu.be/UH6dFbiX_hM)
js2 9y ago
Here’s the thing. I read the Meltdown and Spectre papers after getting frustrated with the hand-wavy descriptions people were writing about the vulnerabilities. I wish I’d just read them in the first place. They aren’t that long and they aren’t that hard to follow. So I recommend developers read the original papers. That said: after reading the papers trying to explain the issues to someone else will test your own understanding, so I don’t mean to dismiss what you’ve written. Aside: I find “so you don’t have to” in the title to be a little off putting.
- cmrdporcupine 9y ago
  I agree, I sat around at work (@Google) for an hour having my brain muddled by 3 or 4 extremely more-intelligent-than-me engineers giving their explanations, and then sat down and read the very clear paper (complete with example C code) and understood it myself in 10 minutes.
  - tomcam 9y ago
    Would you please link to the original paper? Been looking for it myself
    - jwilk 9y ago
      https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf https://spectreattack.com/spectre.pdf https://spectreattack.com/spectre.pdf
      - tomcam 9y ago
        Great stuff! Thanks
    - captn3m0 9y ago
      Here's the PDF: https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf (I found it extremely readable as well, adding a note on the post)
tptacek 9y ago
I might be wrong about any of these points. Here goes: * I don't think Meltdown depends on eager (both-branch) speculative execution. * Memory access during speculative execution almost has to work (and does on AMD and ARM), so that's not the problem. The problem is that permission checks on memory pages are done asynchronously on Intel, and may not abort execution until after footprints have been left in cache. * You can't use memory writes to store the locations of transient memory reads because the instructions are transient, will never be retired, and so can't affect the architectural state (things overtly visible to programs). It's not that the CPU designers realized and specifically prevented that line of attack from working. * It's not that cache state doesn't seem to be rolled back; it's that you can't roll it back. Modern computers are themselves small distributed systems. Changes on shared caches have to be coordinated. You'd be trading one race condition for another. * Exception suppression isn't necessary for the attack because otherwise your process crashes. That's fine: you just run more processes. It might not be necessary to suppress exceptions at all, except that exception handling adds overhead and thus noise to your measurements. Also: the suppression technique you describe here is an oversimplification of Spectre; in reality, Meltdown deals with this with signal handlers or (probably better still) TSX. Finally: I'd recommend not telling people to avoid the actual paper. Your summary is about as technical as Meltdown's is anyways. It's a great paper; more people should read it.
- nkurz 9y ago
  I don't think Meltdown depends on eager (both-branch) speculative execution. I think you are being overly gentle responding to this flaw in the explanation. Not only does the bug not depend on both-branch speculative execution, I don't think there even exist any x64 processors that do both-branch speculative execution. I'm almost certain that all modern Intel x64 processors do branch-prediction and speculatively execute only the branch that they predict as most likely. If that guess is later proved wrong, they throw away the executed but not-yet-retired instructions and execute the correct path. Am I wrong about this?

rocqua 9y ago

I think the specter paper stated that the CPU doesn't run both branches at the same time. Instead it picks one based on speculation and runs that branch. If it picked wrong it rolls back and only then does it start running the other branch. The article states different. If I'm right that would also require some specter-like attack to make sure the desired branch is actually executed speculatively. Alternatively, maybe you can catch the exception and use that to indicate the desired branch was run.

scott_s 9y ago
You're correct that's how speculative execution works: it picks one branch, it does not pick both branches. But that's the Spectre vulnerability, while this article is trying to explain Meltdown, and Meltdown does not involve speculative execution. (See my other comment in this thread for a full explanation.)
- rocqua 9y ago
  Thanks, you comment was really clear :)

DiffEq 9y ago

How easy or how likely is a meltdown attack likely to be successful against a moderately protected PC or say a VMware Cluster...these kinds of things seem hard to pin down...and if all one can do is READ - exactly what is to gain here? It seems that the machine would have already had to have been compromised in another way to get the memory that has been READ off and out of the computer system.

captn3m0 9y ago
There are known PoCs for Meltdown using JS, which is what made this so scary. Heartbleed was far worse in comparison since it was remotely exploitable. But the JS vectors for Meltdown make it scary.
- jnordwick 9y ago
  Where? We've been told it is possible, but I have yet to see a JavaScript exploit that wasn't basically a canned demo.
  - unclepresent 9y ago
    I doubt it is possible to be done on JavaScript. Timing cache access is a challenging task for such high level language. The key to the attack is to figure out latency of memory access. A JavaScript app that is dealing with 100 layers of intermediate code before it actually gets to the physical memory could not see a difference between reading from actual memory or from cache. It is too slow to notice any change. Should be a pure assembler code to reliably estimate the effect of caching.
    - jnordwick 9y ago
      If you are already running untrusted binaries, there are bigger issues. Without a JS exploit, I'm not sure this is a big problem. And we haven't seen a real world binary version either. The versions I've seen all take running starts so to speak.
bennofs 9y ago
The problem is that it bypasses sandboxes and isolation features... normally, JavaScript running in a VM in a sandbox in your browser cannot read all of your memory. With meltdown, that could be possible. Although for that scenario, you need to combine Meltdown with Spectre variant 1, allowing you to read arbitrary kernel memory from JavaScript in a browser.
willvarfar 9y ago

bitexploder 9y ago

Nice write up. One of our guys wrote a similar piece. https://www.carvesystems.com/blog/meltdown-spectre.html https://www.carvesystems.com/blog/meltdown-spectre.html One of the biggest challenges describing low level systems vulnerabilites like these is you have to actually learn at least a little about the CPU internals and high level explanation only gets you so far. I think adding a "why this matters" to your post is helpful.

captn3m0 9y ago
This is helpful, thanks. I'll update this post with your recommendation. Planning to read the Spectre paper next week and do another blog post. Edit: Just read your blog post, definitely need to add a "what's this about", and a "what you should do" section.

ikeboy 9y ago

The first section on cache timing seems off. "The one which is being read is cached, and the exception will be raised much faster as a result." I only read the project zero post, not the paper, but I don't recall it having anything to do with timing of exceptions. I don't see the point or relevance of this section. Might be missing something. Edit: mixed up Meltdown with Spectre, I'll take a closer look at this later

kahnjw 9y ago
The attack relies on side channel attacks, specifically Flush+Reload, which uses timing to find accessed memory locations in another program, as stated in both the paper and this summary. It is definitely relevant.
- deleted 9y ago
  [deleted]
captn3m0 9y ago
The "flush+reload" mentioned in the Project Zero blog[0] is a variant of cache-timing attacks. The original Flush+reload paper has more details[1], but I intentionally didn't delve into the specifics of Flush+Reload. The description I've used is more closer to Evict+Time actually. If you're interested, I recommend this presentation[2] for more details on the category of attacks. [0]: https://googleprojectzero.blogspot.in/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.in/2018/01/reading-privil... [1]: https://eprint.iacr.org/2013/448.pdf https://eprint.iacr.org/2013/448.pdf [2]: https://conference.hitb.org/hitbsecconf2016ams/materials/D2T1%20-%20Anders%20Fogh%20-%20Cache%20Side%20Channel%20Attacks.pdf https://conference.hitb.org/hitbsecconf2016ams/materials/D2T... (Youtube: https://youtu.be/UH6dFbiX_hM https://youtu.be/UH6dFbiX_hM)

js2 9y ago

Here’s the thing. I read the Meltdown and Spectre papers after getting frustrated with the hand-wavy descriptions people were writing about the vulnerabilities. I wish I’d just read them in the first place. They aren’t that long and they aren’t that hard to follow. So I recommend developers read the original papers. That said: after reading the papers trying to explain the issues to someone else will test your own understanding, so I don’t mean to dismiss what you’ve written. Aside: I find “so you don’t have to” in the title to be a little off putting.

cmrdporcupine 9y ago
I agree, I sat around at work (@Google) for an hour having my brain muddled by 3 or 4 extremely more-intelligent-than-me engineers giving their explanations, and then sat down and read the very clear paper (complete with example C code) and understood it myself in 10 minutes.
- tomcam 9y ago
  Would you please link to the original paper? Been looking for it myself
  - jwilk 9y ago
    https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf https://spectreattack.com/spectre.pdf https://spectreattack.com/spectre.pdf
    - tomcam 9y ago
      Great stuff! Thanks
  - captn3m0 9y ago
    Here's the PDF: https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf (I found it extremely readable as well, adding a note on the post)

tptacek 9y ago

I might be wrong about any of these points. Here goes: * I don't think Meltdown depends on eager (both-branch) speculative execution. * Memory access during speculative execution almost has to work (and does on AMD and ARM), so that's not the problem. The problem is that permission checks on memory pages are done asynchronously on Intel, and may not abort execution until after footprints have been left in cache. * You can't use memory writes to store the locations of transient memory reads because the instructions are transient, will never be retired, and so can't affect the architectural state (things overtly visible to programs). It's not that the CPU designers realized and specifically prevented that line of attack from working. * It's not that cache state doesn't seem to be rolled back; it's that you can't roll it back. Modern computers are themselves small distributed systems. Changes on shared caches have to be coordinated. You'd be trading one race condition for another. * Exception suppression isn't necessary for the attack because otherwise your process crashes. That's fine: you just run more processes. It might not be necessary to suppress exceptions at all, except that exception handling adds overhead and thus noise to your measurements. Also: the suppression technique you describe here is an oversimplification of Spectre; in reality, Meltdown deals with this with signal handlers or (probably better still) TSX. Finally: I'd recommend not telling people to avoid the actual paper. Your summary is about as technical as Meltdown's is anyways. It's a great paper; more people should read it.

nkurz 9y ago
I don't think Meltdown depends on eager (both-branch) speculative execution. I think you are being overly gentle responding to this flaw in the explanation. Not only does the bug not depend on both-branch speculative execution, I don't think there even exist any x64 processors that do both-branch speculative execution. I'm almost certain that all modern Intel x64 processors do branch-prediction and speculatively execute only the branch that they predict as most likely. If that guess is later proved wrong, they throw away the executed but not-yet-retired instructions and execute the correct path. Am I wrong about this?