Live data from Hacker News

Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

raspberrypi.org

121–130 of 232 posts

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

#121
post #60

Earlier quoted context omitted.

> This one is limited to 5 to 20 us resolution to prevent such attacks. * make such attacks more difficult.

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

The 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.h...

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

#122
post #95

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

It'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.

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

#123

Earlier quoted context omitted.

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

Very old in the arena of cryptography.

No one in the CPU Architecture Design arena put 2 & 2 together [1] to realize that the same side channel that was devastating for cryptography work would also be quite devastating for bypassing memory permission protections in the CPU's they were designing.

[1] probably because the intersection of "cryptographers who can mount timing side channel attacks" and "CPU Architecture designers" is very close to zero.

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

#124
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)

I think "merit" may be the word you are looking for.

https://en.wiktionary.org/wiki/merit

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

#125
post #24

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

ARM Ltd has a list of vulnerable cores [1], the above are not listed. [1] https://developer.arm.com/support/security-update

I didn't imply they are vulnerable.

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

#126

Earlier quoted context omitted.

(Asking for my own edification) What does the output of branch predictor get used for in a CPU without speculation?

In a pipelined CPU, you want to start the memory fetches for which instructions to next feed into the instruction decoder, before the branch instruction has finished the execute stage. Otherwise every branch incurs a pipeline bubble.

If you're doing speculative memory fetches, wouldn't that also leave a measurable impact on the cache?

Simply instead of MOV AX, [something that depends on secret value] as in the original Meltdown paper you'd need to use JMP [something that depends on secret value] to trigger the memory fetch in a branch that's not going to be used.

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

#127
post #110

Now... I am interested in assembly :D Any recommendations ??? Really awesome explanation

I highly recommend http://www.nand2tetris.org/ and the The Elements of Computing Systems book https://www.amazon.com/Elements-Computing-Systems-Building-P...

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

#128
post #59

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

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

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

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

#129
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?)

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

> The leak is only clear in retrospect. Many, many things are only clear after you see how they were done.

However, even at the time of the design it would have been obvious that deferring security checks is a risky design choice.

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

#130
post #55

Earlier quoted context omitted.

People use mainframes to this day for similar reasons.

That doesn't make a ton of sense to me. Aren't mainframe CPUs developed using modern techniques?

Actually, mainframe CPUs are developed using old techniques, which are all of a sudden interesting again. (-:

See for starters this discussion about reinventing the AS/400: https://news.ycombinator.com/item?id=16053518

Post reply on HN