Chip architecture - is the Pi vulnerable?

[cspan]

Betteridge's law of headlines not withstanding, I would like to know if the Raspberry Pi 3 is vulnerable to the kernel memory leak described here:

https://www.theregister.co.uk/2018/01/0 ... sign_flaw/

Before saying "no, it's Intel", please note that at the very bottom of the page, it's indicated that ARM64 has a similar issue, linking to this page:

http://lists.infradead.org/pipermail/li ... 42751.html

I'm hoping the performance hit to the Pi from any kernel patch will be negligible (as hinted in the above link), but that's apparently not the case for most computers with Intel processors. From what I can read, the real fix involves hardware, but the band-aid approach will be a kernel software patch that will be costly, performance-wise.

I'm lucky that my desktop uses AMD.

[jahboater]

The official OS, Raspbian, that most people use for the Pi runs only in 32-bit mode.

[DougieLawson]

AMD aren't even flawed. They're rubbing their hands in glee and writing an extra kernel patch to undo the Intel software fix for their 64-bit chips.

ARM in AArch64 won't be affected either.

Everything I've read is this is a Intel mess again (remember 387).

[cspan]

So I guess that's a no, even though the chip is 64.

I also wonder about Raspberry Pi Desktop, if running on an intel chip.

[DougieLawson]

Raspberry Desktop is still 32-bit to work with as many things as possible. By the time it comes out as 64-bit the Intel hardware mess will be burned into the kernel.

[W. H. Heydt]

Raspberry Desktop is still 32-bit to work with as many things as possible. By the time it comes out as 64-bit the Intel hardware mess will be burned into the kernel.

I think I'd prefer it to be burned *out* of the kernel....

[jamesh]

Betteridge's law of headlines not withstanding, I would like to know if the Raspberry Pi 3 is vulnerable to the kernel memory leak described here:

https://www.theregister.co.uk/2018/01/0 ... sign_flaw/

Before saying "no, it's Intel", please note that at the very bottom of the page, it's indicated that ARM64 has a similar issue, linking to this page:

http://lists.infradead.org/pipermail/li ... 42751.html

I'm hoping the performance hit to the Pi from any kernel patch will be negligible (as hinted in the above link), but that's apparently not the case for most computers with Intel processors. From what I can read, the real fix involves hardware, but the band-aid approach will be a kernel software patch that will be costly, performance-wise.

I'm lucky that my desktop uses AMD.

The bug is almost certainly only in Intel Hardware, since Intel and ARM do not talk they are are likely to have implemented the same bug - if they have that would really be something!. The link you post to re: ARM64 is actually implementing a protection mechanism which I suspect is unrelated to this particular HW bug. However, since very little detail of the specific Intel issue has been released its difficult to tell.

I seriously doubt there will be any performance impact on the Pi kernel due to changes made to fix an Intel HW bug.

[Paul Webster]

they are are likely to have implemented the same bug

probably should have been
"they are are not likely to have implemented the same bug"

[jamesh]

they are are likely to have implemented the same bug

probably should have been
"they are are not likely to have implemented the same bug"

unlikely was what I meant to type! Good spot.

[jojopi]

probably should have been
"they are are not likely to have implemented the same bug"

I suspect the second "are" was a substitute for the "not"/"un-", rather than there being both an extra word and a missing one.

[DougieLawson]

they are are likely to have implemented the same bug

probably should have been
"they are are not likely to have implemented the same bug"

unlikely was what I meant to type! Good spot.

Unlikely is precisely how I read it. ARM is a way superior, British designed micro-processor. Intel have shown their designs to be sloppy on too many occasions. Remember the Pentium FDIV & Pentium F00F bugs.
http://wiki.osdev.org/CPU_Bugs

ARM doesn't appear on that list.

[Heater]

Dougie,

Except the ARM has it's own bugs of course:
http://www.mono-project.com/news/2016/0 ... 64-icache/

And errata:
https://account.arm.com/1eb62d43-db15-4 ... mode=query

Oh, we are not allowed to read that one.

[andrum99]

Sun saw this coming a mile off and put the kernel and user modes in separate address spaces. The Solaris kernel also implements virtual memory for most of the kernel, unlike Linux which uses physical memory access for most kernel code. Unfortunately Oracle then bought them.

The Register article doesn't say that ARMv8 is vulnerable, just that there is a patch to give an extra level of protection against certain types of attack. It does unfortunately imply that ARMv8 is vulnerable, which is most likely an error in the way the article is written.

[Heater]

Dougie,

Seems ARM should indeed appear on the list you presented

"I can confirm that Arm have been working together with Intel and AMD to address a side-channel analysis method which exploits speculative execution techniques used in certain high-end processors, including some of our Cortex-A processors," says ARM public relations director Phil Hughes. "This method requires malware running locally and could result in data being accessed from privileged memory."


So now, what about this pi64, 64 bit Debian I am running on all my Pi 3 ?

[beta-tester]

is this an issue that affects also RPi and we are talking about in this thread?
https://developer.arm.com/support/security-update
https://security.googleblog.com/2018/01 ... -need.html
https://googleprojectzero.blogspot.de/2 ... -side.html

[runboy93]

https://developer.arm.com/support/security-update

Cortex-A53 is not on the list and Raspbian is on 32-bit, so I think Pi users are pretty much safe.

Debian security tracker:

https://security-tracker.debian.org/tra ... -2017-5715
https://security-tracker.debian.org/tra ... -2017-5753
https://security-tracker.debian.org/tra ... -2017-5754

[RaTTuS]

https://www.theregister.co.uk/2018/01/0 ... erability/
sort of...
it's all down to speculative execution ...

see
https://cyber.wtf/2017/07/28/negative-r ... user-mode/
for the start of it all

[jahboater]

I don't believe the Cortex-A53 does speculative execution.
The faster OOO processors will.

[pootle]

It would be nice to have a definitive statement from the foundation on the vulnerability of *all* the pi models. While it is obvious that Intel have a stratospheric level snafu, all the CPU manufacturers also have nasty but more difficult to exploit couple of problems.

CERT think the only foolproof solution is to replace your CPU if it is vulnerable to any of these modes of attack (!)

There is a good explanation of the overall situation on theregister.

[jamesh]

It would be nice to have a definitive statement from the foundation on the vulnerability of *all* the pi models. While it is obvious that Intel have a stratospheric level snafu, all the CPU manufacturers also have nasty but more difficult to exploit couple of problems.

CERT think the only foolproof solution is to replace your CPU if it is vulnerable to any of these modes of attack (!)

There is a good explanation of the overall situation on theregister.

We cannot make such a statement at this because the issue is still under investigation at Arm. My suspicion is that early models are fine, and probably all are, but we do need to wait and see.

Here is the original report, interesting but very complex reading.

https://googleprojectzero.blogspot.co.u ... e.html?m=1

[6by9]

It would be nice to have a definitive statement from the foundation on the vulnerability of *all* the pi models. While it is obvious that Intel have a stratospheric level snafu, all the CPU manufacturers also have nasty but more difficult to exploit couple of problems.

CERT think the only foolproof solution is to replace your CPU if it is vulnerable to any of these modes of attack (!)

There is a good explanation of the overall situation on theregister.

Based on the information released by ARM

The majority of Arm processors are not impacted by any variation of this side-channel speculation mechanism. A definitive list of the small subset of Arm-designed processors that are susceptible can be found below.

ARM1176, A7, and A53 cores are NOT listed as they don't support out of order execution (as documented at https://en.wikipedia.org/wiki/List_of_A ... hitectures), therefore all current(*) Pi products should not be vulnerable.
Obviously should ARM update their guidance we'll review the situation.

(*) That is not anything about future products, just acknowledging that people ressurect old posts and could otherwise take that out of context.

[Heater]

It's OK James. Javascript is so slow on the Pi it's impossible to get the required timing precision to pull of the attack.

More seriously, this exploit does require you run malicious code on your Pi. Don't do that!

Or at least try not to.

Don't visit dodgy websites.

Don't download and run executable code from random, untrusted, websites.

[jdb]

Interestingly, this exploit chain works solely because of the unintended side effects of having a processor that's "clever". For example, one step of the exploit chain that allows for reading of arbitrary process memory requires that you corrupt the branch prediction state by deliberately causing collisions between your (malicious) process jumps and the victim process jump instructions. In such states the "cleverness" is being manipulated behind the scenes to change what is ultimately an assumption about the benign jump and then let the other "clever" bit - speculative execution - leave traces in memory state that can be visible to others.

I think exploits of these classes will disappear completely in CPUs in the next architectural cycle. ARM have already published a whitepaper describing a processor control flow fence instruction that allows for disabling "cleverness" by forcing deterministic execution time and memory accesses.

For software, the next round of cryptographic algorithms already incorporate pseudorandom memory walks and constant-size memory accesses to mitigate cache manipulation. The whitepaper also talks about using the ARM data/instruction fences to prevent speculation - a useful feature to have if you want to prevent your kernel code from becoming a "gadget" that an attacker can use - sprinkle DSBs everywhere.

[Heater]

Sounds like the wite paper and other suggestions just add more "cleverness".

The "clevernesss" we have now, pipelines, caches, branch prediction, speculative execution, etc, etc is all there to gain performance. All be it at the cost of deterministic execution.

Surely disabling that is a performance hit we don't need. But might be great for real-time systems.

[gdt]

I think exploits of these classes will disappear completely in CPUs in the next architectural cycle

That's probably a little too optimistic. This class of problems -- microarchitectural side channel attacks -- have been known since 2005 [1] but used as attacks on cryptography systems. The introduction of crypto instructions into general-purpose CPUs attracted cryptography researchers interested if the same techniques could be applied to general purpose processors; culminating in CacheBleed [2], etc. Given that success the researchers have more recently applied the techniques to finding and exploiting microarchitectural side channels against other processor functions -- mostly using cache timing side channels [3]. In this latest case the side-channel is instruction speculation. But general-purpose CPUs have many other side-channels that have yet to come under close scrutiny.

The Intel "Meltdown" flaw can be easily fixed with a revision to an existing design, as a bump within a generation. Assuming Intel want to sell CPUs in the next few years, we can assume they have spent the past six months working on such a bump.

The speculative-execution "Spectre" flaw in all Intel, AMD, POWER, zSystem, SPARC, MIPS, ARM models with speculative execution can be fixed with an architectural modification. As you say, by the next architectural cycle. Of course there is considerable business risk attached to that simple statement: you wouldn't want to be the firm trailing other CPU designs which have already corrected the flaw. As a result this flaw is likely to lead to a shortening of the expected CPU design cycle (which is usually based upon process changes, rather than microarchitectural security enhancements).

Closing that "Spectre" speculative-execution side-channel doesn't solve the problem. There are so many side channels in a modern CPU that researchers will simply find another. Which will in turn take another architectural change to avoid. You can see what may happen here with a "whack-a-mole" approach: there may rarely be a point where a CPU doesn't have a known and exploitable vulnerability. This isn't to say that the Spectre mole should not be whacked, but that this whacking won't be sufficient to ensure security.

To avoid this outcome processor designs will adopt the same rigorous approach to side channels as done by their cryptography semiconductor design counterparts. That learning, process re-engineering and re-design is unlikely to take just one architectural cycle to complete. It also contains cultural challenges for semiconductor companies as this sort of security is very much about control of the design process itself, and to date semiconductor companies do not divulge the finer details of their designs nor the finer details of their design processes.

You could expect cloud providers to demand such fine detail before making a major investment in a company's CPU for their compute cloud. Imagine being a compute cloud provider today -- somewhere between 10% and 30% of the CPU cycles they have paid for are gone, and they have clients upset by being charging the same price for less processing throughput. Cloud providers will probably need to reduce pricing for some clients whilst at the same time putting aside cash for a wholesale replacement of all their compute cloud CPUs (and thus mainboards).

It's good news that the Raspberry Pi 3 with its non-speculative Cortex A53 is clear of the current mess. There is no guarantee about what other possible side-channels may or may not be present for future similar events which I expect in the coming years. No large-sales semiconductor design has yet done the groundwork to be able to give such assurance.

[1] DA Osvik, A Shamir, R Tromer, "Cache attacks and countermeasures: the case of AES". 2005-11.
[2] Y Yarom, D Genkin, N Heninger. "CacheBleed: a timing attack on OpenSSL constant time RSA". 2016-10.
[3] Y Yarom, K Falkner. "FLUSH+RELOAD: a high resolution, low noise, L3 cache side-channel attack". 2014-10.