Live data from Hacker News

Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown

raspberrypi.org

51–60 of 232 posts

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

#51
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

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

They are obviously way differently powered CPUs, but if they were as incomparable as you suggest then this article wouldn't even exist.

It doesn't even matter though, I said technical details aside...

I'm not stupid i know a pi zero is slow, but it's a cheap computer that happens to be invulnerable to three really bad sidechannel attacks that plague all big shiny expensive ones. How is that not a little amusing. Not any more now I've had to argue for it.

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

#52
post #42
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…

There is almost certainly a branch predictor even in these simple ARM cores.

There's no reason to predict a branch if you're not going to execute speculatively.

I need to re-read the papers but I think the real problem isn't even speculative execution but allowing speculative cache changes.

The notion that "gadgets" didn't even need to return properly was both amusing and eye opening for me. It doesn't matter because the result will be flushed anyway! ;-)

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

#53
post #11
post #2

With all the news about these attacks lately, this is one of the best posts I've seen in explaining to less knowledgable people how exactly speculation causes a problem. One question I still have that gets glossed over is how timing of instructions is captured.

in order to exploit it from a script running in a web-browser: there's a high-resolution timer in javascript. This one is limited to 5 to 20 us resolution to prevent such attacks. Recently a shared-memory extension has been proposed. one javascript thread just increments a counter in the shared memory, functioning as a clock for the other thread. In both cases, (Spectre) attacks can be prevented by browser updates, s…

> 5 to 20 μs resolution

Updated for those of μs confμsed by this μngainly grammar

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

#54
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

And yet, my abacus is even more secure ;-)

Only if you managed to find a flaw in the arm cores used in the Pi.

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

#55

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

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

#56
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

And yet, my abacus is even more secure ;-)

There might be some side-channel attacks if your rows are too close to each other....

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

#57

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

Modern DDR4 SDRAM can run up to 2133Mhz, but DDR SDRAM is designed to increase speed by taking advantage of CPU caches. For peak performance reads occur in batches so one read command also fill the cache with nearby data.

SRAM can go fast since that’s what caches are made with, but that’s expensive. Also it would need to be close to the CPU as wire latency is non-trivial at high clock speeds.

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

#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 the absence of a cache).

To me it would make a lot more sense to use a special value to indicate the read did not succeed and propagate this value until it is time to crash. I guess this introduces some overhead (e.g. reserve a special value); but are there any other drawbacks?

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

#60
post #11

Earlier quoted context omitted.

in order to exploit it from a script running in a web-browser: there's a high-resolution timer in javascript. This one is limited to 5 to 20 us resolution to prevent such attacks. Recently a shared-memory extension has been proposed. one javascript thread just increments a counter in the shared memory, functioning as a clock for the other thread. In both cases, (Spectre) attacks can be prevented by browser updates, s…

> 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.
Post reply on HN