19 ms·
Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
- Osiris 9y agoWith all the news about these attacks lately, this is one of the best posts I've seen in explaining to less knowledgable people how exactly speculation causes a problem. One question I still have that gets glossed over is how timing of instructions is captured.
- benwaffle 9y agoOne way would be to use the rdtsc instruction, which reports how many cycles have been executed since the processor was reset.
- 1_2__4 9y agoWhich is precisely why Firefox is releasing an update that tweaks high resolution timing. I guess tweaks probably means breaks for some uses cases but that’s likely unavoidable and worth it.
- chriszelazo 9y agoI defintiely agree
- vardump 9y agoUsing rdtscp is better in this case than rdtsc, because it's a serializing instruction. So speculation (instruction reordering) itself doesn't affect the results.
- Fronzie 9y agoin order to exploit it from a script running in a web-browser: there's a high-resolution timer in javascript. This one is limited to 5 to 20 us resolution to prevent such attacks. Recently a shared-memory extension has been proposed. one javascript thread just increments a counter in the shared memory, functioning as a clock for the other thread. In both cases, (Spectre) attacks can be prevented by browser updates, so any performance impact is not system wide. This is different from Meltdown, which (only?) affects intel. That one requires kernel changes which cause system-wide performance degradation.
- blattimwind 9y ago> This one is limited to 5 to 20 us resolution to prevent such attacks. * make such attacks more difficult.
- Spivak 9y agoImpossible. This attack relies on detecting the timing between a cache hit and miss. If your clock resolution is larger than a cache miss then you can't differentiate the two events and so no information is leaked.
- rocqua 9y agoNot quite. An instruction that takes 1us is much less likely to start and end in a different 20us clock cycle than a 10us instruction. Simple repeated sampling combined with statistics still yields a timing attack. It'll be slower and less deterministic, but it's still a problem.
- Symmetry 9y agoYou can wait for a random period on the scale of the clock then measure and take statistics on the results. It will slow down the attack but not stop it.
- msbarnett 9y agoRight, but all this does is close off one possible avenue for a clever attacker to cobble together an HRT. Given the sheer number of JS APIs that have been thrown into browsers, I think it's pretty naive to imagine that we've closed off the only possible avenue to jury-rig a sufficiently precise measure of time.
- deleted 9y ago[deleted]
- 21 9y agoThe GPS signal in below thermal noise at ambient temperature [1]. Using your logic you would say that then it would be impossible to extract. However, with clever math you can extract a signal which is below the noise floor. Particle physicists are experts at this, extracting tiny signals from huge piles of noisy data. [1] https://sdrgps.blogspot.co.uk/2016/02/find-signal-in-noise.html https://sdrgps.blogspot.co.uk/2016/02/find-signal-in-noise.h...
- lxe 9y agoThis article wonderfully explains a complex context without losing a lot of relevant detail.
- SomeHacker44 9y agoThis is a good overview of modern, superscalar, out-of-order, speculative CPUs that literally any programmer could easily understand. Recommended reading for every single engineer in the whole world (who doesn't already understand this stuff from reading source material e.g., Google Zero post).
- el_benhameen 9y agoAgreed. This was the best of the explanations I've read, and it helped me to finally wrap my mind around the exploits.
- vinn124 9y agoagreed
- DrTung 9y agoMe too. Finally I understand how the leakage works: no actual reading of kernel memory is taking place. Instead, the read-ahead/speculative logic causes one of two addresses in user space to be read, and thus placed in the cache. So, by reading both of them, and checking the time it took, the exploit can indirectly determine one bit (0 or 1) of kernel memory. Scary!
- foobarian 9y agoWhat are the exploits enabled by this? Seems like mostly security-related attacks on encryption keys and such.
- infinite8s 9y agoWell that value has to still be read into the cache, since the "kern_mem[address]&0x100" calculation is speculatively carried out. I don't think the MMU can do any bit level computations.
- crispinb 9y agoYes, CPU architecture is one of many subjects I don't know enough about, and this was both interesting & has added to my reading list. It's also quite fun to think that the little Pi I have chugging away in a tiny corner doing a variety of background tasks, which was already the most trouble-free machine I own, may also be the safest (OK I know that's an oversimplification, but I'm feeling affectionate towards it).
- zakk 9y agoThe best explanation of Meltdown I’ve read.
- deleted 9y ago[deleted]
- blattimwind 9y ago> The lack of speculation in the ARM1176, Cortex-A7, and Cortex-A53 cores used in Raspberry Pi render us immune to attacks of the sort. I didn't check, but these will almost certainly have branch prediction. What they probably lack is a predictor advanced enough to speculate on indirect branches, which AIUI is the primary vector of Spectre.
- edsouza 9y agoARM Ltd has a list of vulnerable cores [1], the above are not listed. [1] https://developer.arm.com/support/security-update https://developer.arm.com/support/security-update
- blattimwind 9y agoI didn't imply they are vulnerable.
- trynewideas 9y agoEben delves into some unaffected speculative ARM features in the comments, and why they're not vulnerable. His responses in the comments in general are also worth a read, in case folks skip comments as a rule.
- Scaevolus 9y agoBranch prediction alone is insufficient. Speculative execution alone is insufficient. You need speculative memory loads for any of these attacks to work. The Cortex-A53 branch predictor [1] does prefetching to keep the core fed. This ensures that the instructions are ready for decoding, but has no architectural effects beyond the L1 instruction cache, which is already a well-studied timing sidechannel. [1]: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0500d/CJHEICEB.html http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....
- bazizbaziz 9y agoWhat about the fact that these instructions might get partially executed in the pipeline before the branch gets resolved and the pipeline flushed? If a mis-fetched instruction can reach the LSU stage before the pipeline gets flushed, it might serve as a speculative memory load...
- 646754375 9y agoDidn't ARM say the Cortex A53 is vulnerable to Meltdown?
- tomxor 9y agoTechnical details aside, I find it quite amusing that the hardware in my pi zero is more secure than my desktop that is two orders of magnitude more expensive
- Zaak 9y agoWell, the vulnerabilities are directly connected to performance-enhancing architectural features, so...
- deleted 9y ago[deleted]
- tomxor 9y agoWhich is why i said technical details aside. I think it's interesting, you are not just paying for speed, you are paying for a compromise, because the speed is gained through complexity, which not only increases the chance of error (by design or implementation) but in the case of a high degree of speculative execution can translate into worse performance per watt. In short, it's the whole "more is less" thing.
- Zaak 9y ago> you are paying for a compromise Very good point. Apparently including at least one compromise that most people (probably including the engineers who designed the CPUs) didn't know they were making.
- Demiurge 9y agoAnd yet, my abacus is even more secure ;-)
- trynewideas 9y agoOnly if you wear gloves while using it and shake it after finishing a calculation.
- pslam 9y agoThe cores in (all versions of?) Raspberry Pi do speculatively execute. It's just that the window of opportunity is tiny - just a few cycles (and maybe up to twice that many instructions) - and there's (probably) no way to get an indirected side-effect. I wouldn't write off the ability to get a useful side-effect signal. The variants widely documented are not the only possible methods of inducing speculative side-effects.
- ant6n 9y agoPlus, the Raspberri Pi does have a BTAC (Branch Target Access Cache). Part of Spectre uses the fact that in many architectures the branch target cache is shared across the kernel/user boundary to create a side channel.
- Symmetry 9y agoYes, the Raspberry Pi will issue loads before the branch resolves. But usually a processor's pipeline won't be laid out in such a way that the AGU won't have time to pass an address to the load pipe before the branch resolves and squashes the load. The Cortex A8 was an interesting exception but it was pretty deeply pipelined compared to most in order cores.
- mtgx 9y agoNone of the RISC-V chips are either: https://riscv.org/2018/01/more-secure-world-risc-v-isa/ https://riscv.org/2018/01/more-secure-world-risc-v-isa/
- sitharus 9y agoNice. I wish I could get hold of some inexpensive general purpose RISC-V hardware for hacking on. Hopefully soon!
- tomxor 9y agoMe too, I don't follow the news on it much but I would like it if some single board computers appeared with RISC-V in the not too distant future.
- userbinator 9y ago...nor are 486s, 386s, AVRs, 8051s, and a bunch of other low-performance in-order CPUs. There's also this... https://groups.google.com/a/groups.riscv.org/forum/#!topic/isa-dev/JU0M_vug4R0 https://groups.google.com/a/groups.riscv.org/forum/#!topic/i...
- tomxor 9y agoThat's a little unfair, the RISC-V design is intended for both low power and high power applications, in implementation is has the potential to be comparable to the Pi 3's Cortex-A53. Where as the two 86s you mention are very old slow CPUs and the other two you mentioned are 8bit microcontrollers.
- vardump 9y agoYay, so my AVR and 8051 "usermode" code can't read kernel data. Phew!
- deleted 9y ago[deleted]
- jtchang 9y agoThis is a fantastic read. Timing attacks are insidious and tend to crop it in the oddest places. I first learned of them when learning how to securely compare strings (used a lot with passwords). A naive implementation means that you can easily guess if a character is correct depending on how fast the compare function returns.
- ksearch 9y agoI believe that you now know that every time you do this(comparing passwords as Strings) a puppy dies!
- ksearch 9y agoSorry. Is this crude? Don't really understand down votes.
- grzm 9y agoI suspect the downvotes are because the comment is pretty light on substance as well as being a tired meme. HN members typically value good, substantive, constructive comments and try to keep the signal to noise ratio up as best they can. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
- ksearch 9y agoThank you.
- Franciscouzo 9y agoYou shouldn't be comparing plain text passwords anyway. You should be using a secure password hash, such as bcrypt, sure, you should use constant time comparison, but in this specific case, it won't really make you vulnerable to use normal comparison.
- ufo 9y ago
- styfle 9y agoI understood everything up until the "suppose we flush our cache before executing the code" part which is probably the most important part. There was a comment below the article that explained this part a little further: > Imagine the value at the kernel address, which gets loaded into _w, was 0xabde3167. Then the value of _x is 0x100, and address user_mem[0x100] will end up in the cache. A subsequent load of user_mem[0x100] will be fast. > Now imagine the value at the kernel address, which gets loaded into _w, was 0xabde3067. Then the value of _x is 0x000, and address user_mem[0x000] will end up in the cache. A subsequent load of user_mem[0x100] will be slow. > So we can use the speed of a read from user_mem[0x100] to discriminate between the two options. Information has leaked, via a side channel, from kernel to user. https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/#comment-1375375 https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne...
- JdeBP 9y agoYes, that is the this is left as an exercise for the reader part of the explanation. (-: The remaining part is to iterate the process over all of the bits in the word, using different bitmasks. The resultant set of 0 or 1 results for each bit yields the complete word. Then one iterates that whole process over all (useful) words in (mapped) kernel memory.
- rofex 9y agoThanks, this was the missing piece in my understanding. I was wondering how only knowing only 1 bit would be useful. Suppose the attacker wants to read this entire address (0xabde3167) using this method. Is it guaranteed that over multiple runs, this address would be the same each time at that point in execution?
- ufo 9y agoIt is certainly possible that the memory the exploit is trying to read might be changing under its nose. An actual implementation of the exploit would need to account for that.
- 9y ago
- deleted 9y ago[deleted]
- tptacek 9y agoThis is great, but remember that it covers Meltdown, not Spectre. Meltdown is the more immediate disaster, but Spectre is the more batshit vulnerability. You really want to get your head around: * The branch target injection variant of Spectre if you want to get a sense of how amazing this vulnerability is: you can spoof the branch predictor to trick a target process into running arbitrary code in its address space! This is crazy! * The misprediction variant of Spectre if you want to get a hopeless feeling in the pit of your stomach, since the implications of mispredict are that certain kinds of programs are riddled with a new kind of side channel we didn't really grok until last week, and no upcoming microcode update seems to be in the offing. You could probably use the same Python conceit to illustrate the other two attacks; someone might take a crack at that. (I'm not disputing that the R-Pi's aren't vulnerable to Spectre).
- claytonjy 9y agoI too would love to see the continuation you suggest. This was a great article, and I was sad to see it end, since I was hoping to grok a little more about the technical differences between Meltdown and Spectre.
- ploxiln 9y agoThis covers both Meltdown and Spectre. > Both vulnerabilities exploit performance features (caching and speculative execution) common to many modern processors to leak data via a so-called side-channel attack. Happily, the Raspberry Pi isn’t susceptible to these vulnerabilities, because of the particular ARM cores that we use. The reason why Spectre is not a problem is because there is no branch predictor in these simpler arm cores. Instructions are processed in parallel when possible, but not before dependencies, including branch decisions. EDIT: under "What is speculation?" branch prediction is described. Then in the conclusion: "The lack of speculation in the ARM1176, Cortex-A7, and Cortex-A53 cores used in Raspberry Pi render us immune to attacks of the sort."
- tptacek 9y agoI'm not arguing that R-Pi's are vulnerable to Spectre.
- lelandbatey 9y agoI've done some cursory searching and not found anything, so I'll ask here: what mechanism is used to measure how long it takes to access a specific address in memory? I assume there is some way to tell the CPU "when memory location X is read, store the current time in register Y" or some such thing. Could anyone share what that mechanism is?
- lucb1e 9y agoElsewhere in the thread, someone asked the same question and got an answer: https://news.ycombinator.com/item?id=16080230 https://news.ycombinator.com/item?id=16080230
- lelandbatey 9y agoThank you for that link! I'll write out the conclusion I came too from reading those comments: Instead of measuring the literal time interval between instructions, the number of cycles between two points is measured (using the RDTSCP instruction).
- Chaebixi 9y ago> In the good old days*, the speed of processors was well matched with the speed of memory access...Over the ensuing 35 years, processors have become very much faster, but memory only modestly so: a single Cortex-A53 in a Raspberry Pi 3 can execute an instruction roughly every 0.5ns (nanoseconds), but can take up to 100ns to access main memory. In real-world terms, what's the fastest processor we could build today whose execution speed is reasonably matched to it's main memory access speed (so it doesn't need caches, etc)? I could imagine that a processor, with a simple design that closely matches a naive model of how CPUs work, would be very useful for high-security applications. It would be much easier to reason about up-front.
- gaius 9y agoIn the good old days, the speed of processors was well matched with the speed of memory access... In fact on the Beeb, spiritual ancestor of the RPi, memory ran at 4Mhz and the CPU at only 2Mhz...
- Chaebixi 9y agoIIRC, some of those old machines interleaved CPU and GPU memory access windows, since memory was so much faster than CPUs back then. Edit: this is what I'm talking about: https://www.bigmessowires.com/2011/08/25/68000-interleaved-memory-controller-design/ https://www.bigmessowires.com/2011/08/25/68000-interleaved-m...: > The Atari ST and Amiga appear to have both used a more aggressive scheme where video circuitry access occurred during known dead time in the 68000 bus cycle, so the CPU never had to wait
- jrowley 9y agoPeople use mainframes to this day for similar reasons.
- Chaebixi 9y agoThat doesn't make a ton of sense to me. Aren't mainframe CPUs developed using modern techniques?
- njitbew 9y agoI enjoyed reading this a lot. I wonder why the developers decided to allow reading kernel-memory in the first place. When a scalar processor reads kernel memory, it crashes. When a speculative processor reads kernel memory, it relies on the assumption that the read is never committed to prevent leakage. It takes no expert to realise this is a potentially dangerous decision (and, as becomes clear now, is only valid in the absence of a cache). To me it would make a lot more sense to use a special value to indicate the read did not succeed and propagate this value until it is time to crash. I guess this introduces some overhead (e.g. reserve a special value); but are there any other drawbacks?
- infinite8s 9y agoThis is the part I don't understand. How is the processor able to read a cacheline from a protected memory page without crashing (even if it was speculative and wouldn't happen in the idealized execution due to branching).
- teacpde 9y agot, w_ = a+b, kern_mem[address] u, x_ = t+c, w_&0x100 v, y_ = u+d, user_mem[x_] if v: # fault w, x, y = w_, x_, y_ # we never get here Form the author's example, it seems like the processor is able to read the kernel memory privately (`w_`) and crashes if the code attempts to commit `w_` to `w`. It would be interesting to know how the processor does that.
- pwg 9y agoBecause in the Intel design, for memory reads issued by speculative instructions, any "access denied" results are also delayed until the CPU control unit determines the instruction that issued the read should really have been executed. But the actual read from is allowed to occur, even if the "access denied" signal is given. Which allows the read to effect the state of the data caches. This was likely done this way as a performance booster, because this would allow speculative instructions to also perform cache pre-fetching during their speculation window. That seems to be why AMD CPU's are immune to Meltdown. AMD's design prevents the read from occurring when the "access denied" signal appears, so the cache state is not effected, so there is no side channel to detect.
- criddell 9y agoI've been wondering (and haven't seen it addressed anywhere) if these attacks could be used to get the private key out of game consoles. These days I would assume not - that the key would be in a secure enclave - but the current generation of consoles are a few years old now and maybe that's not the case.
- jenscow 9y agoThe private key used to sign code? No, that wouldn't be in the console at all.
- confounded 9y agoI imagine they mean the decryption key (rather, the ‘private, encryption’ key).
- zackmorris 9y agoOk I think I understand the subtleties of these attacks now. But: can anyone tell me why the accessibility check for protected memory doesn't happen before the cache loads the contents of RAM? If that happened then none of these attacks would be possible. I got my computer engineering degree in 1999 and ended up going the computer science route making CRUD apps all day. I feel in my gut that some engineer, somewhere, MUST have asked this question at one of the big chip manufacturers. Am I missing something fundamental? Is the access check too expensive? If it isn't, then can the microcode be updated to do this, or is caching/accessibility checking happening at a level above microcode? If that's the case then it would seem that pretty much all processors everywhere that do speculation without protected memory access checks are now obsolete.
- userbinator 9y agoThe memory access could potentially take a very long time, so it makes sense to start it as early as possible, in parallel with all the other operations. Saving a few cycles on each memory access adds up significantly overall.
- drb91 9y agoRight, but at a cost of a leaky cache abstraction. Which is now hugely expensive to work around, making me question how that ever got approved if the security model was clearly leaking at that point (which has been known for the entirety of speculative execution, right?)
- userbinator 9y agohow that ever got approved if the security model was clearly leaking at that point Keep in mind that for a very long time, PCs and x86 CPUs were used in environments where either there was a single user with full access, or multiple users that aren't completely adversarial (look at Win95/98's multiuser security model, for example.) Memory protection and other security features served as a barrier to accidents and to "keep the honest honest", not determined adversaries. They still are today, but this is very different from the shared servers/cloud computing environments which have now become common --- completely mutually untrusting users with possibly adversarial relationships are sharing the same hardware. This is the reason why all the CPU manufacturers have had some variant of "as designed" in their public comments --- speculative execution was designed with the former model in mind, not the latter.
- daveheq 9y agoDoes anyone expect bug revelations after this to be less worse, or is there still a chance there could be vulnerabilities that are worse than these?
- InclinedPlane 9y agoIt's hard to imagine something worse to be honest. These vulnerabilities basically amount to ripping away the entire veil of protections at every level that we've built up over the years. Future vulnerabilities that I could imagine being "worse" would be either encryption vulnerabilities or signals level vulnerabilities.
- O_H_E 9y agoNow... I am interested in assembly :D Any recommendations ??? Really awesome explanation
- teacpde 9y agoI highly recommend http://www.nand2tetris.org/ http://www.nand2tetris.org/ and the The Elements of Computing Systems book https://www.amazon.com/Elements-Computing-Systems-Building-Principles/dp/0262640686/ref=ed_oe_p https://www.amazon.com/Elements-Computing-Systems-Building-P...
- O_H_E 9y agoThanks :)
- jtgeibel 9y agoOff topic, but I haven't seen this discussed anywhere yet. My understanding is that font files can contain complex instruction sequences to control exactly how a font is rendered. I believe Windows implements a kernel space VM to execute these instructions. I know variants 1 and 2 did not necessarily require eBPF but that it made the attack simpler because the desired instruction sequences could be injected directly into kernel space (rather than finding existing sequences in the code base). It seems that in theory font rendering could serve a similar function on some platforms.
- matte_black 9y agoWhat would finally bring this all together to me would be an example of a real world attack that would be carried out using these methods on some target, perhaps with an implementation.
- oblib 9y agoSince it was an industry effort to find the flaw, and they are vulnerable to the threat they've exposed, it would seem at odds to their interests (and my own) to provide you or anyone else with an example of how to exploit it. And I'll offer that if you're not capable of demonstrating it after reading Eben's description of how it works than there is no good reason for you to have an example handed to you. If you think you are capable I'll offer your time would be better spent working on fixes.
- thingification 9y agoI was already on the lookout for a small ARM-based mini PC, just for doing financial transactions and record-keeping. Now that seems more pressing but I don't know of any such thing in existence. I tried doing that on RPi 3, but the IO seemed not up to the job -- the CPU appeared to be just about tolerable, but using micro SD as a disk was too slow and prone to failure (I'd have tried an external USB disk but I believe the problems were in part because of poor I/O bandwidth). Other single board machines seemed to have better provision for disks that are up to the task I had in mind, but lack software support, so that I had little confidence in security updates, for example. If somebody sold this I think they'd have my money tomorrow: * An ARM mini-PC * With a decent security update team behind it (probably the hard part?) * That will let me run some basics: for me, a Unixy OS with Chrome/Chromium, emacs, ledger and python, without a big effort to install those and keep them up to date * Ideally without too much anti-commodification BS (from my customer perspective) so that hardware can be swapped out if needed Does anything like that exist?
- isr 9y ago(coming late to this thread ...) arm-powered chromeboxes don't exist (yet?), so perhaps an arm-powered chromebook? (chromeboxes tend to be more upgradeable than their chromebook counterparts) Linux OS, kept up to date for you (with google backporting security fixes to their kernel, and of course - updating their browser), running on arm. Can be used as a simple browser-only machine, or if you are decently comfortable with linux, you can unlock its potential and use it as a fully-fledged linux machine. Your choice. If you want to avoid being part of the google foodchain, you could try dual-booting into another arm distro of your choice. Best I can think of, at the moment ...
- 21717117 9y agoAndroid?
- shasheene 9y agoSD cards are optimized for sequential IO (reading/writing photos, video, music). For an OS root partition, random IO is much more important for general use. If the root partition is mounted from an external USB drive with higher random 4K IOPS benchmarks, IO performance should be greatly improved.
- greguu 9y agoHey, what about Intel Xscale processors like the PXA2xx series ? These do have Dynamic branch prediction/folding afaik and may be affected ? Does somebody have a spectre.c tuned for generic armv5tel for example? Current versions of spectre.c, like this one https://gist.github.com/LionsAd/5116c9cd37f5805c797ed16fafbe93e4 https://gist.github.com/LionsAd/5116c9cd37f5805c797ed16fafbe... still contain "_mm_clflush" and therefore do not compile on ARM at all.
- aplorbust 9y agoHow many RPi users are using this board to run untrusted code? The RPi may mitigate risk of these attacks simply in the way it is used. Perhaps hobbyists use it to run their own small programs, not random third party Javascript in an enormous web browser from some corporation.
- mirthflat83 9y agoFantastic read. Before reading the article, I assumed there were many HN readers who were extremely proud about their Raspberry Pi being invulnerable to Spectre or Meltdown
- oblib 9y agoThe best comment made on that blog post was by Eben himself: "One almost wishes that they’d stuck with the original name for the KPTI patchset: Forcefully Unmap Complete Kernel With Interrupt Trampolines. https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ https://www.theregister.co.uk/2018/01/02/intel_cpu_design_fl... " Now that's funny!!!