Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

raspberrypi.org

Post reply on HN
Print view View original

101–110 of 232 posts

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

#101

Post by tomxor »

Zaak wrote: post #18
tomxor wrote: post #16

Technical 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

Well, the vulnerabilities are directly connected to performance-enhancing architectural features, so...

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

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

#102

Post by [deleted] »

Spivak wrote: post #60
blattimwind wrote: post #15

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.

[deleted]

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

#103

Post by PuffinBlue »

SomeHacker44 wrote: post #4

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

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 discarded, and execution will continue. If we time a subsequent access to one of those addresses, we can determine which address is in the cache. Congratulations: you’ve just read a single bit from the kernel’s address space!

To my understanding it is that saying that by...

1) ...flushing the cache so you have a 'clean' state, you can get...

2) ...the speculative execution to 'pull in' to cache the address user_mem[x_] but...

3) ...the particular address that's pulled into cache, 0x000 or 0x100, is determined by whether...

4) ...the illegal read of kern_mem[address] 8th bit was a 1 or 0...

5) ...which you can then subsequently determine the value of by...

6) ...timing how long it takes to access that user_mem[x] address once again and...

7) ...thereby leaking the value of kern_mem[address]...

So you still have to perform some logic on the result of the speed of the access to the secondary address read right?

If read of 0x000 is slow you know kern_mem[address] was a 1 and if fast kern_mem[address] a 0, and if 0x100 is slow you know kern_mem[address] was a 0 and if fast that kern_mem[address] was a 1?

Is that correct?

If it is it seems that timing is the key right, and actually the clever leap of creativity in completing the exploit, at least to my untrained mind.

Please do correct anything I've got wrong, I'm not an engineer/developer!

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

#104

Post by Chaebixi »

jrowley wrote: post #55
Chaebixi wrote: post #44

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

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?

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

#105

Post by pilom »

PuffinBlue wrote: post #103
SomeHacker44 wrote: post #4

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

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

#106

Post by tomxor »

userbinator wrote: post #78
mtgx wrote: 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...

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

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

#107

Post by teacpde »

infinite8s wrote: post #85
njitbew wrote: 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).

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

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

#108

Post by tomxor »

sitharus wrote: post #58
mtgx wrote: post #19

None of the RISC-V chips are either: https://riscv.org/2018/01/more-secure-world-risc-v-isa/

Nice. I wish I could get hold of some inexpensive general purpose RISC-V hardware for hacking on. Hopefully soon!

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

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

#109

Post by wrcwill »

AnsemWise wrote: post #91
zackmorris wrote: post #67

Ok 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,…

I hope I understand your question correctly. The request asks for something in protected memory and also asks for something based off a portion of the protected memory (like the first byte). The system denies access to the request then puts both results in cache. The attacker then asks for a byte of memory similar to the second request, which the system tries to get from cache but then goes to memory since it wasn't…

this is for meltdown right? how would you explain the difference between this and spectre, going from this explanation?
Post reply on HN