Why Raspberry Pi Isn't Vulnerable to Spectre or Meltdown • Hacker News Board

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

#151

Post by thingification » Fri, Jan 05, 2018, 11:32 PM UTC

I was already on the lookout for a small ARM-based mini PC, just for doing financial transactions and record-keeping. Now that seems more pressing but I don't know of any such thing in existence.

I tried doing that on RPi 3, but the IO seemed not up to the job -- the CPU appeared to be just about tolerable, but using micro SD as a disk was too slow and prone to failure (I'd have tried an external USB disk but I believe the problems were in part because of poor I/O bandwidth). Other single board machines seemed to have better provision for disks that are up to the task I had in mind, but lack software support, so that I had little confidence in security updates, for example.

If somebody sold this I think they'd have my money tomorrow:

* An ARM mini-PC

* With a decent security update team behind it (probably the hard part?)

* That will let me run some basics: for me, a Unixy OS with Chrome/Chromium, emacs, ledger and python, without a big effort to install those and keep them up to date

* Ideally without too much anti-commodification BS (from my customer perspective) so that hardware can be swapped out if needed

Does anything like that exist?

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

#152

Post by msbarnett » Fri, Jan 05, 2018, 11:36 PM UTC

simias wrote: post #145

PeterisP wrote: post #126

Earlier quoted context omitted.

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.

Not if you're just trying to avoid a bubble in you pipeline and not actually executing the opcodes speculatively. In this situation the code will be loaded (and probably decoded etc...) but not executed before the CPU made sure that the branch was actually taken. If it's not the pipeline is flushed and a bubble is introduced after all. It's not as efficient as executing speculatively out of order but at least if you…

> Not if you're just trying to avoid a bubble in you pipeline and not actually executing the opcodes speculatively. In this situation the code will be loaded (and probably decoded etc...) but not executed before the CPU made sure that the branch was actually taken.

Here's what I'm trying to figure out. Let's say there's a JIT-generated instruction that I, an attacker, am interested in learning but cannot directly read from my position in the sandbox. If I can influence the instruction fetch speculator to issue a load for that instruction, then AFAICT it doesn't matter that it never makes it as far as the execute stage -- merely the act of fetching it for decode will have had a side-effect I can probably exploit into determining what it was.

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

#153

Post by tzs » Fri, Jan 05, 2018, 11:39 PM UTC

ProblemFactory wrote: post #86

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

> can anyone tell me why the accessibility check for protected memory doesn't happen before the cache loads the contents of RAM? From what I understand, it does happen on AMD, which is why AMD CPUs are not vulnerable to the more dangerous Meltdown attack (any code reading kernel / hypervisor host memory). Intel / ARM delays the checks until later, to the time when the speculated instructions are actually finalised an…

Too bad segmentation was dropped for 64-bit code on x86, leaving just page tables. 32-bit x86 retains the segmentation model of the 286, extending it to 32 bits, and making it work with virtual addresses instead of physical addresses if the paging system is also enabled.

Most 32-bit operating systems ignored the segmentation system, basically just running everything in what the old timers would call "small model".

If we had segmentation in 64-bit mode, then I wonder if we could defend against a lot of these problems by running things we want to sandbox, such as JavaScript, in a different segment that only has access to the upper end of our virtual address space?

As long as the sandboxed code cannot change the segment registers, this would prevent it from generating an address outside the sandboxed portion of the processes' virtual address space.

I don't recall if the x86 segment system provides a way to trap attempts to change a segment register. If I recall correctly, it does support more than just the two level kernel/user protection system, and I think it supports not allowing loading a segment register with a selector that refers to a segment belonging to a higher level, so maybe if user mode was split into two levels, so sandboxed code could be run at a less privileged level than the main process it could work.

In general, I think processor designers need to take into account the need for processes to run sandboxed code, and provide some kind of mechanism the processes can use to protect themselves from malicious code in the sandbox.

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

#154

Post by make3 » Fri, Jan 05, 2018, 11:47 PM UTC

tialaramex wrote: post #135

O_H_E wrote: post #112

Earlier quoted context omitted.

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

Not in general. Consider an Olympic 100 metre sprinter. Today we time this event very accurately, I think it's to one hundredth of a second, using sophisticated technology. But even if the judges used a much less accurate mechanical stopwatch, Usain Bolt wouldn't actually be slower, we'd just be less confident of how ridiculously fast he is. In some special cases, timing things very accurately might be essential to a…

gotta get that sweet rollover effect right to the 24th decimal baby

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

#155

Post by 21717117 » Fri, Jan 05, 2018, 11:55 PM UTC

thingification wrote: post #151

I was already on the lookout for a small ARM-based mini PC, just for doing financial transactions and record-keeping. Now that seems more pressing but I don't know of any such thing in existence. I tried doing that on RPi 3, but the IO seemed not up to the job -- the CPU appeared to be just about tolerable, but using micro SD as a disk was too slow and prone to failure (I'd have tried an external USB disk but I belie…

Android?

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

#156

Post by sillysaurus3 » Sat, Jan 06, 2018, 12:11 AM UTC

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-news/1406913/posts

"The recent Hyper-Threading vulnerability announcement has generated a fair amount of discussion since it was released. KernelTrap has an interesting article quoting Linux creator Linus Torvalds who recently compared the vulnerability to similar issues with early SMP and direct-mapped caches suggesting, "it doesn't seem all that worrying in real life." Colin Percival, who published a recent paper on the vulnerability, strongly disagreed with Linus' assessment saying, "it is at times like this that Linux really suffers from having a single dictator in charge; when Linus doesn't understand a problem, he won't fix it, even if all the cryptographers in the world are standing against him."

Always found that amusing.

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

#157

Post by davrosthedalek » Sat, Jan 06, 2018, 12:17 AM UTC

makomk wrote: post #146

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…

A lot of the cheaper Pi-like boards also aren't affected for the same reason, as are lower-end Android phones. The articles claiming it affected every modern CPU were basically mistaken. It was an easy mistake to make, given that ARM's announcement only listed the cores that were affected and had a little note saying everything not listed was unaffected by both Meltdown and Spectre. (There is precisely one ARM-design…

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.

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

#158

Post by ghettoimp » Sat, Jan 06, 2018, 12:33 AM UTC

drb91 wrote: post #81

userbinator wrote: post #77

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

In retrospect, yes this is of course a big problem. But regarding how it could ever be approved...

Until this news broke, a CPU designer would tell you that speculative execution is a well-understood, proven approach to gaining a lot of performance. Branch predictors are really good at figuring out where the next instruction is going to come from, and are a really important tool for avoiding stalling out the whole machine while you wait for the next instruction to come back from memory.

And intuitively, it seems really "safe." All you're doing is having the CPU get ready to perform "future" calculations more quickly. It gets to guess where the program is going to go, and start fetching resources that it thinks will be needed. As long as nothing architecturally visible is changed by these preparations, everything is functionally the same, so what could go wrong?

And intuitively, you wouldn't think that something like a cache, which the program has no way to access directly, should be architecturally visible. Even putting on a security-minded hat, you would think that it doesn't matter what's in the cache, because if a program tries to access kernel memory, the access still has to undergo a permissions check.

The attack is pretty damn clever. And disheartening.

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

#159

Post by zzzcpan » Sat, Jan 06, 2018, 12:38 AM UTC

davrosthedalek wrote: post #157

makomk wrote: post #146

Earlier quoted context omitted.

A lot of the cheaper Pi-like boards also aren't affected for the same reason, as are lower-end Android phones. The articles claiming it affected every modern CPU were basically mistaken. It was an easy mistake to make, given that ARM's announcement only listed the cores that were affected and had a little note saying everything not listed was unaffected by both Meltdown and Spectre. (There is precisely one ARM-design…

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.

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

#160

Post by jimmies » Sat, Jan 06, 2018, 12:41 AM UTC

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

The explanation is at end of page 4 and begin of page 5 on the meltdown paper. In a nutshell, the speculative feature allows the read to happen, it "doesn't segfault," and only signals the OS of the segfault or whatever until it's actually executed.