Live data from Hacker News

Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

raspberrypi.org

111–120 of 232 posts

Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

#111
post #22

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.

You 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.

Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

#112
post #105

Earlier 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.

Does that mean -another- slight performance drop ???

Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

#113
post #19

None 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...

Yay, so my AVR and 8051 "usermode" code can't read kernel data. Phew!

Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

#114
post #81

Earlier 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…

Isn't the knowledge of potential for timing attacks using cache/memory fairly old? I am pretty sure I heard of the concept long ago.

Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

#115

This 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).

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

#116
post #112
post #105

Earlier 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 ???

It means the only secure system is one where the performance of any given instruction is constant in all cases for that instruction.

Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

#117
post #81

Earlier 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?)

> if the security model was clearly leaking at that point

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

#118

Earlier 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...

They're not partially executed. The branch predictor only fetches instructions. They might be decoded, but it's not an out-of-order processor-- pipeline stages only proceed if the previous phase is correct.

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

#119
post #115

Earlier 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)

"worth" maybe?

Re: Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

#120
post #32

This 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!…

If you don't feel overwhelmed enough by the misprediction variant of Spectre yet, consider that the cache side effect of speculation is actually desirable in most normal cases, because it helps prime caches with data that is likely to be used in the correct branch as well. Just turning it off is not the right way to solve this.

Perhaps this will finally provide enough incentives to model data sensitivity in the type systems of practical programming languages.

Post reply on HN