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

161–170 of 232 posts

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

#161

Post by std_throwaway »

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 feel in my gut that some engineer, somewhere, MUST have asked this question at one of the big chip manufacturers.

Sure, they were about to commit career suicide but then they learned to love the bomb and went on with their day. Maybe they even tried to explain the problem to management but somehow it got lost in translation.

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

#162

Post by tptacek »

sillysaurus3 wrote: post #156
tptacek wrote: 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!…

By the way, didn't cperciva point out this vuln way back in 2005? http://www.daemonology.net/papers/htt.pdf Actually that seems to be rather different, but still similar-ish. They both use threads to exploit memory caches in an unexpected way. I thought he deserved a mention since no one really took it seriously back then. https://it.slashdot.org/story/05/05/13/0520214/hyperthreadin... http://freerepublic.com/focus/f…

Cache timing goes back to at least 2005 with Osvik and Tromer. This isn't a simple cache timing bug, though.

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

#163

Post by tptacek »

JdeBP wrote: post #137
tptacek wrote: 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!…

Microcode updates in the offing: * https://lists.opensuse.org/opensuse-security-announce/2018-0... ( https://news.ycombinator.com/item?id=16081366 ) Future microcode updates mentioned: * https://newsroom.intel.com/wp-content/uploads/sites/11/2018/... ( https://news.ycombinator.com/item?id=16079910 )

Those updates cover Meltdown and Spectre 2, not Spectre 1.

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

#164

Post by tptacek »

DannyBee wrote: post #148
tptacek wrote: 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!…

It's not all that hopeless, actually. Let's ignore meltdown, which seems solvable in hardware with no obvious performance loss (assuming amd's existence proof is correct), and concentrate on spectre, which everyone thinks means the world is ending. One thing to note is that compilers have been safely speculating instructions for years. Shocking, i know :) Processors could too. They just weren't. One of the cardinal r…

I don't think it really is hopeless. But what makes Spectre 1 "scary" is that it's situational: you want to serialize instructions predicating some loads --- unbounded offsets based on attacker-controlled data --- but all of them. You presumably don't want your compiler to lfence every basic block containing a load.

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

#165

Post by tschuy »

lucb1e wrote: post #64
disconnected wrote: post #46

Earlier quoted context omitted.

It isn't funny or witty to point out that an Opel Corsa gets better gas mileage than a 747, even if it is factually correct. I didn't downvote you (can't even do it), but I suspect you are getting downvoted because your analogy is so off the mark that it can't even be called "Apples vs Oranges". edit: replying to the "why the downvotes" which has since been edited away

> It isn't funny or witty to point out that an Opel Corsa gets better gas mileage than a 747 Actually, if it's true that a car gets a better mileage than a big airplane (more in one vehicle = more efficient, people seem to believe) I would find that interesting. Similarly, I can see how OP thinks it's ironic that a very cheap machine is not vulnerable whereas a quite expensive piece of equipment is, making it seeming…

Transatlantic flights average 75 mpg per passenger, but can be up to almost 100 mpg per passenger:

https://en.wikipedia.org/wiki/Fuel_economy_in_aircraft

Jet fuel is 37.4 MJ/L; compare to gasoline at 34.2:

https://en.wikipedia.org/wiki/Energy_density#Energy_densitie...

An electric car will have up to 150 miles-per-gallon equivalent (aka 150 miles per the same amount of energy that's in one gallon of gasoline):

https://en.wikipedia.org/wiki/Miles_per_gallon_gasoline_equi...

So therefore, an electric car with just the driver is more efficient energy-wise than an airplane, while an average airplane is better than a gas car with even three people in it.

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

#166

Post by [deleted] »

tptacek wrote: post #40
ploxiln wrote: post #38

Earlier quoted context omitted.

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

I'm not arguing that R-Pi's are vulnerable to Spectre.

[deleted]

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

#167

Post by ufo »

Franciscouzo wrote: post #111
jtchang wrote: 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.

Normal comparison is bad even if you are comparing hashes. Letting the attacker figure out the password hash allows them to attempt to crack the password through an offline brute-force attack running on GPUs.

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

#168

Post by haimez »

zzzcpan wrote: post #159
davrosthedalek wrote: post #157

Earlier quoted context omitted.

One could argue that CPUs without branch prediction are not modern in the sense of "modern, state of the art design". The fact that they still produce,e.g. 8051, even "new" overall designs, doesn't make the 8051 modern.

Branch prediction is neither new nor modern. Modern state of the art design doesn't actually do branch prediction in hardware at all. I mean look at all the ideas from VLIW architecture, no hardware - no problems.

You're being pretty silly by zeroing in on the word modern and then using an equally silly redefinition of it yourself.

Branch prediction isn't new, you're right. But VLIW instructions are equally unmodern and are entirely orthogonal to speculative execution. Sufficiently smart compilers are also no substitute for runtime analysis.

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

#169

Post by drivebycomment »

DannyBee wrote: post #148
tptacek wrote: 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!…

It's not all that hopeless, actually. Let's ignore meltdown, which seems solvable in hardware with no obvious performance loss (assuming amd's existence proof is correct), and concentrate on spectre, which everyone thinks means the world is ending. One thing to note is that compilers have been safely speculating instructions for years. Shocking, i know :) Processors could too. They just weren't. One of the cardinal r…

Just giving up speculation entirely is too much of a performance penalty. So one possible solution is: when you know it was a misspeculation, processor can just kick cache lines out of cache if the speculation caused the cache line to be loaded (probably you only need to do this at the last level cache closest to the memory). More states to track, but not impossible.

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

#170

Post by CamperBob2 »

pilom wrote: post #105
PuffinBlue wrote: post #103

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.

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.

What does that do, besides turn the exfiltration problem from an immediate one into a statistical one?

Post reply on HN