Processor kernel vulnerabilities

Always good to start the day on a bright note (irony) and people had got round to reading a few IT articles yesterday so…
My boss said cheerfully today “there’s a vulnerability and it affects all processors, including your favourite – ARM – so your OS isn’t as secure as you think”

I replied that

1. Meltdown does not affect ARM, that’s Spectre and so you’re conflating two things
2. RISC OS is every bit as secure as I think it is and always has been.

I didn’t bother pointing out that privilege escalation in RO is an interesting fantasy for reasons we all know.

The interesting effect of patching to cause things to work securely (which Intel clearly avoided) slows things down by up to 30%. Anyone want to speculate why Intel did it the insecure way?

Meltdown does not affect ARM

I think ARM would disagree with you on that one. Cortex-A75 is affected (although El Reg points out that A75 cores aren’t actually commercially available yet), and there’s a variant which affects A15, A57 and A72. Although to me, both Meltdown and Spectre sound as bad as each other, in that a CPU bug/design flaw is allowing code to gain access to information which it shouldn’t be able to access.

I didn’t bother pointing out that privilege escalation in RO is an interesting fantasy for reasons we all know.

And as I’m sure you know, these bugs aren’t about privilege escalation.

The interesting effect of patching to cause things to work securely (which Intel clearly avoided) slows things down by up to 30%. Anyone want to speculate why Intel did it the insecure way?

Because nobody complained about it until now?

And as I’m sure you know, these bugs aren’t about privilege escalation.

User code accessing areas they should not be able to, normally requiring root or similar permissions in essence.
With no security you know where you stand (well exposed)

Because nobody complained about it until now?

I’m presuming they just did something convenient that worked without bothering to cover all all the test points.
A touch of this works so that’s good enough – an attitude that’s brings to mind the errors turned up by the high vector change in that everything worked before (mostly without visible effect) so that was good enough as far as the software authors were concerned.

User code accessing areas they should not be able to, normally requiring root or similar permissions in essence.

But only read-only access (at least until you use the extracted data to exploit a chink in the armour elsewhere). To me, privilege escalation implies both read and write access, so is much more powerful.

I’m presuming they just did something convenient that worked without bothering to cover all all the test points.

When your CPU contains billions of transistors, covering all the test points is rather non-trivial.

I was implying that nothing had been done about it until now because no (good-natured) security researchers had found the issues until recently. As operating systems have become more and more secure, side-channel attacks on hardware are now the “in thing” for researchers to look at (and malware authors to exploit). Meltdown/Spectre is a combination of speculative execution, caches, and high-resolution timers. On their own these features are harmless, and when Intel first introduced the features 10+ years ago I doubt anyone within the company considered that they could be combined in such a way as to allow memory to be snooped (much like nobody at ARM or AMD considered it to be a problem).

There’s only so much that Intel can patch via microcode updates, so until newer CPUs are released which are able to provide hardware mitigations for the attacks, the only solutions are software ones which by their nature make things slower.

When I first read the description of Meltdown I though…hmm, sounds remarkably like the erratum I found in the ARM7 macrocell a few months back…namely trigger an Abort and CPU pollutes the cache with a speculatively executed instruction that’s been incorrectly escalated.

Its not the same issue of course, but is remarkable similar in both execution and outcome.

The “fix” unmaps the kernel data area from what I gather, but what else is in the memory map that could be read though this method? Could it be used to speculatively read hardware devices for example?

Could it be used to speculatively read hardware devices for example?

Unlikely – IO devices should be mapped using Device memory type, which doesn’t support speculative reads (since the hardware might be read-sensitive).

You might be able to use it to read memory buffers which hardware is using, however (e.g. USB & SATA controllers typically store lots of state information in host RAM)

Is this going to have any effect on RO users?

Theoretically, yes. The “Spectre” attack is the one which affects ARM the most (many Cortex cores are susceptible to it), and it can be exploited by Javascript. So if you’re running a browser which supports Javascript and provides access to high-resolution timers then a malicious script could exploit the flaw and read memory which it shouldn’t be able to.

Of course the default RISC OS timer is only 100Hz, and we don’t yet have a proper API for accessing the HAL timers, so I doubt any of the browsers which do support Javascript (or any other programs which might run untrusted scripts within a “secure” sandbox) will be vulnerable.

But, wait, enquiring minds want to know – when will the RISC OS kernel be patched to mitigate this heinous serious OMG problem?

I’ve now seen the technical detail on these exploits, both of which work on the principle of timing instructions to infer memory contents they don’t have access too.

Meltdown exploits an erratum in the CPU implementation of speculative/pipeline execution, where the cache is polluted with data that’s been read speculatively. The only way to “patch” this 100% is disable the cache, partial patching can be done by unmapping sensitive data from memory and flushing the cache, or disable caching of sensitive areas. Patches that have already been rolled out to prevent access to kernel data use the unmap method.

what else is in the memory map that could be read though this method?

AntiVirus and Interrupt Handler data will be in the memory map. No doubt AV vendors will issue patches if not done so already.

Spectre exploits branch prediction and affects all CPU’s that speculatively execute branches, the only way to patch this 100% is disable branch prediction. I’m intrigued as to how this is going to be patched without disabling as its exploiting expected CPU behaviour.

when will the RISC OS kernel be patched to mitigate this heinous serious OMG problem?

PMSL

Eben Upton has posted a very clear explanation of why Raspberry Pi isn’t vulnerable to Spectre or Meltdown. Subsequent discussion expands this, and he has said he will be adding to it in due course.

I’m intrigued as to how this is going to be patched without disabling as its exploiting expected CPU behaviour.

For some bizarre reason ARM have decided the best way to deal with Spectre is to add a new barrier instruction and require software to use it when privileged code accesses data using an array index provided by untrusted code. Which seems like the worst possible solution. Hopefully they’ve just worded things poorly, and this is just a workaround for current CPUs, pending a proper fix for future CPUs.

Since both exploits resolve around being able to use speculative execution to load cache lines (and then measure timing of cache/memory accesses to determine how the cache has changed), my thought is that CPU designers could add a “speculation reference count” to cache line entries. I.e. whenever speculative execution causes a cache line to be fetched, a reference count associated with that cache line is incremented. If the speculative instruction is retired, the reference count will decrease, and if it hits zero the cache line is invalidated, returning the cache to its original state. Only if the speculative instruction is accepted (“architecturally executed”) will the cache line remain in the cache.

If speculative memory accesses are allowed to evict cache lines, then the CPU might also need redesigning to hold any speculatively-fetched cache lines in a queue, so that software won’t be able to detect the speculative access by the fact that a previously-valid cache line has now vanished. Only once the instruction is architecturally executed will the speculative cache line be allowed to enter the main cache (and evict any other line as necessary).

I might be misunderstanding something here, but doesn’t this cache issue imply that the speculative execution totally ignores memory privilege permissions? Why doesn’t the MMU choke and stall the instruction when the processor is not in a sufficiently privileged mode for what the instruction is wanting to do?

Memory access permissions are being correctly adhered to. The attacks don’t actually allow code to read the contents of protected memory, they just allow code to infer the value of addresses that speculatively executed code has been accessing, by checking to see whether the speculative execution has disturbed the cache in any way.

ARM’s whitepaper explains it fairly well – https://developer.arm.com/support/security-update

Or, as a summary:

; R0 comes from untrusted code
CMP R0,#array_size
MOVHS PC,LR            ; Invalid values will halt execution here, but the following code may be speculative executed anyway
LDRB R0,[R1,R0]        ; Speculatively load from an out-of-bounds array offset; could therefore load any address in memory
LDRB R0,[R2,R0,LSL #n] ; Use the first loaded value to perform a second speculative load

If the attacking code can detect a cache line that’s been loaded or evicted by the second load instruction, it can deduce some of the address bits which that load instruction used. If it’s able to deduce enough of those address bits (e.g. by abusing a number of different routines which have different ‘n’ shift values) then it can deduce what value was loaded by the first load instruction. And since it can control the address that the first load instruction accesses, it can use it as a generic way of reading protected memory.

I suppose another solution to the problem would be to make it so that privileged code uses completely separate caches to unprivileged code.

ARM have decided the best way to deal with Spectre is to add a new barrier instruction and require software to use it when privileged code accesses data using an array index provided by untrusted code

It does seem a little odd at first, but makes sense when you consider the mess you’d probably get into trying to implement the obvious solution of invalidating the speculatively accessed cache line for out of bounds accesses.

I suppose another solution to the problem would be to make it so that privileged code uses completely separate caches to unprivileged code

It wouldn’t surprise me if at some point we see processors with dedicated cores for privilege level code which are completely isolated, with their own cache and MMU.

Memory access permissions are being correctly adhered to. The attacks don’t actually allow code to read the contents of protected memory,

Are you sure? While a piece of code cannot directly read inaccessible memory, it seems to me that the basic process is:

• ¹ Try to load a byte from inaccessible memory
• ¹ Do some shifting to load another byte from an address based upon the first loaded byte
• Use some timing magic to see if the cache contains an entry for the second byte load; the timing will be either fast (already cached) or slow (not cached)
• The fast/slow corresponds to the chosen bit in the shift from the first read, essentially one can deduce the contents of protected memory one bit at a time

However, it seems to me that this can only work if the processor is in fact bypassing the MMU and memory access permissions while performing speculative execution (or else where would the value retrieved by the first instruction come from?). The actual executing code obeys the rules, but what the processor is doing internally surely isn’t.

¹ This is code that is not directly executed (it would fault), it is arranged so the speculative execution system will run this in parallel to code that is being executed. When it comes time to make use of this code, it faults and is never actually performed, but traces of its behaviour remain in the way the cache behaves; thus implying the faulting happens at the point of attempting to execute the code, and not when the speculative execution tries to access protected memory, which is why I suggested that the speculative unit is in fact bypassing the MMU’s access permissions.

However, it seems to me that this can only work if the processor is in fact bypassing the MMU and memory access permissions while performing speculative execution

You’re right that it can work if speculative execution isn’t taking into account memory permissions (and it wouldn’t surprise me if some CPUs do suffer from that). And it would certainly explain why there’s been a flurry of OS patches to make sure kernel memory is completely unmapped when processors are running user code (and skimming through the doc, I think that’s what the Meltdown attack is – it runs its attack fully from within unprivileged code)

But in the general case (Spectre), you can perform the attack by making sure that the speculative execution is performed by a privileged OS routine (called from your unprivileged attack code).

it would certainly explain why there’s been a flurry of OS patches

and application patches – the latest version of Firefox on Windows specifically lists it as having a fix for “Meltdown”

I think that’s what the Meltdown attack is – it runs its attack fully from within unprivileged code

From the info I’ve read Meltdown exploits a specific feature of Intel designs which isn’t applicable to other manufacturers. As you say the general case is Spectre, but from the item by Eben even that doesn’t apply to all ARM devices.

All in all has it changed the security situation in RO?
Probably not, simply because it was always pretty much non-existent anyway which was what I was alluding to with “RISC OS is every bit as secure as I think it is and always has been”

All in all has it changed the security situation in RO?

That’s why my post on Friday; because even if RISC OS was running on an affected processor, it’s a waste of time thinking about a kernel patch when the OS memory (and indeed most things except specific DAs that are restricted to SVC access) are generally read/write from user mode (hello RMA), and for those things that need SVC access, it’s a simple call to OS_EnterOS to get privilege. So we clearly benefit from total immunity to the problem by virtue of having zero “security” to begin with. You can’t lose what you don’t have!

You can’t lose what you don’t have!

Well the main item would be remote code attack via something like javascript, but there is the question over how much support for such a javascript based exploit actually exists. As Jeffrey pointed out:

and we don’t yet have a proper API for accessing the HAL timers, so I doubt any of the browsers which do support Javascript (or any other programs which might run untrusted scripts within a “secure” sandbox) will be vulnerable.

Sometimes the lack of features actually has a positive side.

but there is the question over how much support for such a javascript based exploit actually exists.

There is, of course, a wider question to be asked. Why does an interpreted script language running in a browser need access to high resolution timers at all?

I can understand access to a normal timer in various fractions of a second – perhaps centisecond like RISC OS because the old style ticker worked at a weird 18.2 ticks per second, but a timer with a high enough resolution to time cache load differences? Why? [or is x86 just REALLY slow?]

That said – using Javascript, does such a piece of code actually exist? You’d need to write a script to manipulate what the processor does in a very careful way to get the desired effects, plus be able to time behaviour well enough to determine what the cache is up to; while bypassing the overheads of the script interpreter and the browser being ‘polled’ in a preemptive manner (as we’d be talking Windows or Linux here).

Is this even possible? It would be like trying to control what happens in the ARM core by using pure BASIC (no assembler). Surely the act of interpreting the instructions (in whatever manner the interpreter prefers) would destroy the ability to accurately control and time the things we need to control and time in order to make the side channel exploit work.
I’m rather inclined to call bull on this¹ and suggest that the way to make it work is to find some way of exploiting Javascript in order to get a raw executable running on the machine. But, then, that’s no different really to any other malware…

That said – we can trust Google to find a way to eff it up → https://developer.chrome.com/native-client ²

¹ Or does modern Javascript support inline assembler? Nothing would surprise me these days…

² Note, of course, the “Portable Native Client” that is translated to the architecture in use blah blah blah explain to me how this isn’t what Java did decades ago? Oh, wait, Google invented it so it must be better, right?

That said – using Javascript, does such a piece of code actually exist?

Allegedly it can be done in JavaScript without even requiring access to a timer (just have a timing loop running on a second thread).

https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html?showComment=1515144826122#c3412520428104682520

There are also JavaScript implementations of rowhammer.

https://github.com/IAIK/rowhammerjs

Surely the act of interpreting the instructions

Modern JavaScript engines use JIT, so the performance should be pretty good for basic arithmetic and memory access.

This article about PowerPC/X360 was an interesting read!

re X360 – Just proves that bugs are reinvented just as often as wheels.