This 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.
Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
111–120 of 232 posts
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#112Earlier quoted context omitted.
Non-engineer here, this bit is key right: > However, suppose we flush our cache before executing the code, and arrange a, b, c, and d so that v is zero. Now, the speculative load in the third cycle: > v, y_ = u+d, user_mem[x_] > will read from either address 0x000 or address 0x100 depending on the eighth bit of the result of the illegal read. Because v is zero, the results of the speculative instructions will be disc…
You're exactly correct. This is why the browsers decreased timing resolution in javascript so that you couldn't time memory accesses accurately enough to tell if the address was cached or not.
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#113None of the RISC-V chips are either: https://riscv.org/2018/01/more-secure-world-risc-v-isa/
...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/i...
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#114Earlier quoted context omitted.
Right, 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?)
> how that ever got approved if the security model was clearly leaking When you consider a theoretical model of the CPU, then it's not leaking - the speculative execution, cache, other parts of the CPU are designed carefully so that no data can "escape" and be read by processes that don't have the permission to do it. Speculated execution can happen, but before any results from that are released, the permissions are…
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#115This 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).
Yes, 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).
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#116Earlier quoted context omitted.
You're exactly correct. This is why the browsers decreased timing resolution in javascript so that you couldn't time memory accesses accurately enough to tell if the address was cached or not.
Does that mean -another- slight performance drop ???
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#117Earlier quoted context omitted.
The 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.
Right, 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?)
The leak is only clear in retrospect. Many, many things are only clear after you see how they were done.
It has been twenty years since processors with this vulnerability started appearing. Over those two decades, thousands of very smart engineers (including state-sponsored ones) have collectively spent millions of hours of analysis trying to find security flaws.
No one has found such a clever timing attack until now. So "clearly leaking" wasn't "clearly leaking" until this week.
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#118Earlier quoted context omitted.
Branch 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://in…
What 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...
Here's the Cortex-A53 pipeline: https://www.anandtech.com/show/11441/dynamiq-and-arms-new-cp...
It's an in-order CPU, so that "issue" phase (pipeline step 5) stalls until the instruction pointer is resolved. Instructions must be issued to the "AGU Load" functional unit, which is what actually performs the read and pulls data into the cache hierarchy.
Note also that a single speculative memory load is insufficient for Spectre. You need two speculative memory loads.
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#119Earlier quoted context omitted.
Yes, 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).
Finally the minimalist approach proved its ..... (I lost the word, non English speaker, but you did understand me :D)
Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown
#120This 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!…
Perhaps this will finally provide enough incentives to model data sensitivity in the type systems of practical programming languages.