Spectre 3a & 4
About this Article
On May 21, two new processor design issues (collectively called Spectre-NG together with 6 more yet to be disclosed issues) were published.
One is called variant 3a and indeed is a variation on Meltdown (v3), just that this time the contents of architecturally protected system registers can be retrieved by an attacker rather than memory contents. Read more about this in section Variant-3a.
Variant 4 is a new attack with somewhat similar traits as Spectre-v1. Here, the CPU speculatively executes a store followed by a load to the same memory address which the memory disambiguator fails to detect, so the load does speculatively load stale data. Via cache effects the stale data can be exposed again to the attacker. Read more in the section Spectre_4.
Like all the other (so far known) Spectre/Meltdown issues, these two are Information Disclosure flaws that require an attacker to run code on the target hardware.
Variant-3a
This flaw has been researched and published by ARM and some of their CPUs are affected. The attack works like Meltdown, just that this time a system register is read speculatively rather than protected memory: While the CPU is waiting for some memory data, it speculatively performs a read on a system register (debug register, control register, machine specific registers) and uses the result to calculate the address of another read. While the CPU cleans up the speculatively read data once it asynchronously determines that the system register read was not allowed, the cache effects remain and can be measured by classical cache timing techniques, leaking information from the system registers that are architecturally only accessible at higher privilege levels.
The issue is known to affect some (but not all) ARM big-cores and intel CPUs. There is currently no information from AMD, but given the proximity to the Meltdown (variant 3) attack, AMD may be unaffected from this. There is no good reason for a privilege level check to not be performed synchronously before speculative access (no slow memory access is needed to determine the current privilege level), so it's somewhat surprising to see CPU designers creating vulnerable CPUs.
This vulnerability has been assigned CVE-2018-3640 and is named Rogue System Register Read (RSRE).
The good news is that the system registers tend to not contain too many secrets; ARM advises to not do any mitigation beyond clearing or filling in dummy values for sensitive system registers before switching to lower privilege levels -- this would be used to protect KASLR. intel announced that future microcode updates would fix this issue. As accesses to system registers do not happen very frequently, restricting speculation on their access is not expected to result in measurable performance impact.
Spectre-4
The microcode updates from intel are in beta-testing currently with intel partners; we hope to get official microcode soon that can be deployed to Open Telekom Cloud.
When CPUs do stores to memory locations and loads from the same address later on, the CPU needs to make sure that even for out-of-order / speculative execution, the current value is used and not an old one. Indeed, if the CPU determines that a load depends on a store, it ensures that it waits for the store value to be determined and uses this one (store forwarding).
The determination also is done speculatively by the memory disambiguator (MD). Unfortunately, it can miss cases where the address is the same (because it's calculated in different ways involving addresses that are not yet known), so it's possible that a stale value is speculatively loaded.
This vulnerability leverages the same trick then to make the speculatively loaded stale piece of data visible as all the others: Using memory accesses with data dependent addresses that then cause cache effects that are not undone when the processor rolls back the misspeculation.
This issue has been researched and found by Microsoft and Google's Project Zero.
This CPU flaw hits many modern CPUs, amongst which ARM big cores, all OoO intel CPUs, AMD CPUs, Power, System-z, and others.
It has been assigned CVE-2018-3639 and is referenced as Speculative Store Bypass - SSB.
This flaw does expose data that is supposed to be overwritten; this happens for example when cryptographic code overwrites secrets in memory to avoid sensitive key material to remain in memory. The flaw itself does not expose data from higher privilege levels, but data that was overwritten, sometimes for a good and security-relevant reason.
In this way it is very similar to Spectre-v1. The attack surface is again managed code, where interpreters/JITs such as the javascript interpreters in browsers or the eBPF runtime do clear memory before allowing access from managed code to ensure there is no information leakage. This leakage protection now can be subverted using the attack against the SSB flaw.
So to mitigate the flaw, we either need to get the CPU to never have memory disambiguation do a misprediction, or selectively or globally disable speculative loads while stores are outstanding. A global disablement however would be expected to have severe performance consequences.
ARM has introduced two new barrier instructions that allow to selectively prevent loads from overtaking stores that software developers can use to secure critical code.
intel has beta microcode that support the ability to switch on and off Speculative Store Bypass (SSBD = Speculative Store Bypass Disable). Using it globally however has a severe performance impact; unlike the performance hit from Spectre-v2 and Meltdown-v3 which is incurred at context switches, the disablement of speculative loads prior to all previous stores being retired has a more uniform impact -- intel states 2%--8% in system benchmarks.
intel thus recommends to only switch this on for processes that need it. intel also mentions that the fact that high precision timing measurements are not possible any more from the javascript engines of popular browsers make exploits difficult to do from browsers.
The microcode is not yet available in a stable version -- intel suggests partners to deploy the stable microcode as soon as its released but leaves the decision to deploy the beta microcode to the customers and partners and their test results. After the disasters from the January microcode screw-up, I expect the appetite for beta microcode to be limited though ...
We are currently working without partner Huawei to determine whether we have sufficient test results to deploy beta microcode with confidence.
Allegedly, AMD does not require microcode updates.
Hypvervisors and Kernels
As of 2018-05-22, the upstream Linux kernel and KVM have received patches to make use of SSBD as soon as microcode is there to provide the feature in the CPU. Code for this has been merged in the 4.14.43 long-term kernel release.
Linux distributors are providing updated kernels and hypervisors. Advisories have been published by RedHat, SUSE and Ubuntu. Ubuntu has already published updated kernels, while the kernels from SUSE and RedHat are expected in the next days.
The SSBD usage can be controlled by a kernel command line option spec_store_bypass_disable=auto|seccomp|on|off|prctl. The default will selectively enable SSBD for eBPF, for seccomp protected programs (browsers) and for processes that ask for this via prctl. This limits the performance impact.
We will provide updated public images on OTC as soon as the kernels with the workarounds have been published.
Unfortunately, this will not help much until we also deploy the new microcode and expose it to the VMs from the hypervisors. We will announce this in our May and June OTC patching pages.