11 ms·
Things you must know before you can understand Meltdown as a developer
- captn3m0 9y agoTried 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 agoI 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 agoYou'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 agoThanks, you comment was really clear :)
- DiffEq 9y agoHow 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 agoThere 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 agoWhere? 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 agoI 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 agoIf 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 agoThe 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 agoNice 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 agoThis 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 agoThe 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 agoThe 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 agoThe "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 agoHere’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 agoI 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 agoWould you please link to the original paper? Been looking for it myself
- jwilk 9y agohttps://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf https://spectreattack.com/spectre.pdf https://spectreattack.com/spectre.pdf
- tomcam 9y agoGreat stuff! Thanks
- captn3m0 9y agoHere'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 agoI 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 agoI 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?
- d33 9y agoSuggestion - this logo: https://razorpay.com/blog/content/images/2018/01/34873319-a5d02762-f7ba-11e7-8eca-4e04f2bd4522.png https://razorpay.com/blog/content/images/2018/01/34873319-a5... Should probably say "Intel" somewhere ;)
- agumonkey 9y agopotential animated gif https://www.youtube.com/watch?v=Q6Zrnv4OtbU&feature=youtu.be&t=213 https://www.youtube.com/watch?v=Q6Zrnv4OtbU&feature=youtu.be...
- als0 9y agoThat doesn't seem completely fair. The ARM Cortex-A75 is affected. Furthermore, the A72 and A57 also suffer from a different variant of Meltdown.
- deleted 9y ago[deleted]
- Blazespinnaker 9y agoI am surprised this hasn’t been explained in terms of a vulnerability chain. Ie, break it up into parts. As soon as you have an oracle providing cache timing info you have a vulnerability. Basic Bayesian analysis suggests that there is more fruit to fall off the tree.
- scott_s 9y agoI agree: as long as side channel attacks are possible, there's always the possibility that someone else will find some other vulnerability that can be combined to create an exploit. The paper (https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf) does present it in that way: they show you the parts, then show how they fit together for a workable exploit.
- phkahler 9y agoI don't understand one part. If you read from an arbitrary memory location (during speculative execution, I get all that) how does that read pull data from a different process? Aren't all addresses virtual until they go through the MMU and get translated to a physical address depending on the process? Or does this work only because the kernel exists in the same virtual address space, hence KPTI as a mitigation?
- bennofs 9y agoYes, meltdown only works if the kernel is in the same address space. Also, the kernel maps the whole physical memory as part of its address space somewhere (kernel phyiscal map), so if you can read kernel memory, you can read all phyiscal memory. And you are right, KPTI is a full fix for Meltdown (but not Spectre).
- tedunangst 9y agoIt is typical for 64 bit machines to have a direct mapping of physical memory at some virtual offset. Ie, virtual 0xfffff...700000 corresponds to 0x0 physical. This simplifies some things since you can allocate and access any physical page without creating new mapping. 32 bit machines do not typically have sufficient kernel address space to do the same. (Oh, linux still uses direct map on 32 bit machines even today, but only maps some memory? I thought that was abandoned, but wouldn't really know. Anyway, a much better explanation of all things direct map is https://www.sceen.net/mapping-physical-memory-directly/ https://www.sceen.net/mapping-physical-memory-directly/)
- bogomipz 9y ago>"This simplifies some things since you can allocate and access any physical page without creating new mapping." I am curious what types of things does this simply for the kernel? When is a physical page allocation ever done that doesn't need to be entered in into a page table entry?
- tedunangst 9y agoptrace of another process, for instance.
- jgrahamc 9y agoMy explanation: https://blog.cloudflare.com/meltdown-spectre-non-technical/ https://blog.cloudflare.com/meltdown-spectre-non-technical/
- 33W 9y agoGreat analogy, explanation, and illustrations. Thanks for sharing.
- scott_s 9y agoUnfortunately, this gets some big things wrong. Meltdown is not about speculative execution. (Spectre is.) Meltdown is about out-of-order execution - no branches required. The authors are clear about this in the paper. From Section 2.1: "In practice, CPUs supporting out-of-order execution support running operations speculatively to the extent that the processor’s out-of-order logic processes instructions before the CPU is certain whether the instruction will be needed and committed. In this paper, we refer to speculative execution in a more restricted meaning, where it refers to an instruction sequence following a branch, and use the term out-of-order execution to refer to any way of getting an operation executed before the processor has committed the results of all prior instructions." In this explanation, the author starts by showing two different code branches, which is misleading. Meltdown does not require code branches - which is what makes it so surprising. This is the C code example from the paper: raise_exception(); // the line below is never reached access(probe_array[data * 4096]); No branches: you have an exception, and then in the code following that exception, you have some memory access. Despite the exception, the access happens because of out-of-order execution. The actual exploit is, in assembly: ; rcx = kernel address ; rbx = probe array retry: mov al, byte [rcx] shl rax, 0xc jz retry mov rbx, qword [rbx + rax] The exception is raised on the mov command, as it loads a kernel address. This exception will eventually cause the processor to abandon all of the current code it is executing, and the program will terminate from a segmentation fault. But. There is a race condition: before the processor deals with the exception, but after the memory has been accessed, the second mov instruction executes, which uses the data which caused the exception. This shouldn't matter, as execution is abandoned, but data is brought into the cache based on this value, and using side-channel attacks, we can figure out what this value was. From the paper: "To load data from the main memory into a register, the data in the main memory is referenced using a virtual address. In parallel to translating a virtual address into a physical address, the CPU also checks the permission bits of the virtual address, i.e., whether this virtual address is user accessible or only accessible by the kernel. As already discussed in Section 2.2, this hardware-based isolation through a permission bit is considered secure and recommended by the hardware vendors. Hence, modern operating systems always map the entire kernel into the virtual address space of every user process. As a consequence, all kernel addresses lead to a valid physical address when translating them, and the CPU can access the content of such addresses. The only difference to accessing a user space address is that the CPU raises an exception as the current permission level does not allow to access such an address. Hence, the user space cannot simply read the contents of such an address. However, Meltdown exploits the out-of-order execution of modern CPUs, which still executes instructions in the small time window between the illegal memory access and the raising of the exception." I find the paper to be very readable. They give a good overview of modern computer architecture, and then walk through all of the steps of their attack. I highly recommend reading it: https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf
- koolba 9y agoHow many bits per second (or kbps, mbps, etc) of memory reading is possible with Meltdown when run from JS vs running natively? Somewhat related, is it possible to neuter the JS engines in Firefox or Chrome so that they don't JIT JS and would doing so have any real world impact on mitigating this attack? If it relies on speedy execution to be possible maybe a solution would be to have a NeuterScript extension that deliberately slows things down.
- lykr0n 9y agoTo do it fast enough will peg the browser to 100% cpu for that thread. Saw a demo on twitter where they were not reliably able to extract information from the browser. Native, as in not running inside a browser, has been shown to be able to extract information reliably. My guess is the extreme amount of overhead that is required to run JS in an isolated-ish way. I think the point is that a JS based attack, while possible, would be much use outside proof of concept
- captn3m0 9y agoRelated to your second question: both Chrome and Firefox are deliberately increasing resolution of performance.now APIs to reduce ease of precision timing attacks.
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- unclepresent 9y agoHere is the same in 10 lines of pseudo-code http://zergo.me/meltdown.html http://zergo.me/meltdown.html
- hafta 9y ago> var BASE_ADR=zzzz;//Make BASE points to a random 256 bit currently uncached memory block that appplication has access to; That should be 256 bytes.
- unclepresent 9y agoyep, corrected. at the end it is a bit more complex than that as cache is populated in 32-128 bytes increments but I leave it out for simplicity
- keldaris 9y agoAs others have already said, if you're a programmer, please just read the original papers: https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf (start with this one) https://spectreattack.com/spectre.pdf https://spectreattack.com/spectre.pdf They are extremely well written, clear and to the point. Understanding them will take you less time than trying to get rid of all the tortured analogies and unnecessary simplifications people have been trying to make up over the past week. It's bad enough that we face the daunting task of explaining this stuff to people who don't care about computers, there's no need to perpetuate misunderstanding among those who deal with computers for a living. Just read the real thing. And on the subject of explaining this to others, it might surprise you how far you can get if you try to honestly explain how the attacks work. I refuse to use the silly train station metaphors, so I tried to describe the basic idea of how speculative execution works in out of order CPUs to my parents (who can browse the Internet, with some effort, and were patient enough to listen to me for 10 minutes or so). I don't think I got the notion of return-oriented programming across very well, but the basic idea of Meltdown and side channel timing attacks in general is actually very easy to convey on the basis of a reasonably simplified picture of a CPU - you need the explain the basic role of cache memory, virtual vs physical addressing, the TLB and the basic notion of branch prediction. That's all you need to understand the principle of how the attacks work, if not the details of the implementation.
- taeric 9y agoDon't be too quick to dismiss metaphor based explanations. You'd probably be surprised how many developers need the metaphor. Similarly, many folks explaining this are likely doing so as much to increase their understanding as anything else. If there are problems in their explanation, help make it clearer. None of this is to say that folks should skip the originals. But it is also not helpful to constantly send folks back to them.
- scott_s 9y agoThe problem is that some of the metaphor based explanations are wrong, and are decreasing understanding. When the originals are clearer than the attempted simplifications, then I do think it's helpful to send people to them.
- bogomipz 9y agoI have a couple question about Meltdown and the Intel chips. My understanding is that a key part of this is that upon speculative execution the page table permission checks only happen when the "transient"instruction is retired. Was this simply a performance engineering trade off made by Intel? Would checking the PTE permissions on speculative execution result in giving up any performance gained by the speculative execution?
- xroche 9y agoCache line is 64 bytes on x86-64 if I am not mistaken, not 4096 :) Nice read anyway.
- tptacek 9y agoThings 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 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.
- gautamb0 9y agoI 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.
- sdevlin 9y agoThey'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.
- tptacek 9y agoIs 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.
- konschubert 9y agoMy naive expectation would have been that the CPU maintains some kind of process level isolation. My new understanding is now that the concept of a process and isolation of processes is handled by the kernel. This is probably a silly question, but maybe we could handle process isolation in the CPU somehow?
- mr_toad 9y agoI doubt you’d want to implement the process scheduler in hardware, it would be very inflexible.
- Animats 9y agoSome CPUs can fetch data from memory they are not currently entitled to fetch. The permissions checking is done in parallel with the fetch, so a fetch and even some use of the data can take place. The result can't propagate back as a result to the program, if the retirement unit is doing its job, but can affect cache loads. So how early does that chain of events have to be stopped? If it's stopped before the unwanted fetch, security is sound - the CPU never pulls in the data it shouldn't see. Future CPU designs are probably going to have to do that, even at some cost in performance (but look for complicated explanations from Intel as to why this isn't really necessary). That may require more permission info in the various tables and caches of the memory system. Even if the memory interface looks at page permissions earlier, there's the possibility of using this attack to peek at data in the same address space, data protected only by checks in the code. This may allow snooping around within application programs such as browsers. It used to be that you only worried about timing issues for speculative execution in crypto code. It's important that strong encryption code take constant time regardless of the data. Otherwise, timing measurements of known-plaintext attacks may yield info about the key. Now it's a broader problem. Bleah. Fortunately, my CPU designer friends are all retired now and don't have to deal with this.