This repo is an attempt to collect information on the class of information disclosure vulnerabilities caused by CPU speculative execution that were disclosed on January 3rd, 2018.
Existing nomenclature is inconsistent and there is no agreed-upon name for the entire class of bugs, but the names Spectre and Meltdown have been used for subclasses of attacks.
This is a combination of publicly available information and educated guesses/ speculation based on the nature of the attacks. Pull requests with corrections or discussion are welcome.
All of the attacks cause information disclosure from higher-privileged or isolated same-privilege contexts, leaked via an architectural side channel, typically the CPU data cache. The basic premise is that CPU speculative execution is not clean and can persistently alter such microarchitectural state, even when the speculated instructions are rolled back and should never have run. Malicious software can trigger these "impossible" instruction sequences and then observe the result through a side channel, leaking information.
This is a CPU bug that violates the isolation guarantees of the architecture. Future CPUs are likely to include partial hardware solutions as well as require OS cooperation (i.e. an architecture definition change adding requirements to system software). Pure software- or hardware- based solutions are unlikely to be comprehensive or have acceptable performance.
The specific exploits involve various ways of exploiting speculative execution. Different CPUs from various vendors are affected in different ways, and software mitigations also vary.
So far, all exploits rely on exfiltrating data via the data cache. A value is speculatively obtained, then an indirect load is performed that can bring in data into the cache from a different address depending on one or more bits of the value to be leaked.
Google name: Variant 1: Bounds check bypass
Research name: Spectre
CVE: CVE-2017-5753
The CPU mispredicts a branch and speculatively executes code which leaks sensitive data into a data cache load.
Sample code:
unsigned long untrusted_offset_from_caller = ...;
if (untrusted_offset_from_caller < arr1->length) {
unsigned char value = arr1->data[untrusted_offset_from_caller];
unsigned long index2 = ((value&1)*0x100)+0x200;
if (index2 < arr2->length) {
unsigned char value2 = arr2->data[index2];
}
}
If untrusted_offset_from_caller
is out of bounds, the CPU may speculatively
read value
and then cause a cache load from arr2
that depends on it. The
attacker can then profile loads from arr2
(directly or by invoking other code)
to determine which cache line was loaded, and thus one bit of value
.
The attacker need not necessarily control arr2
directly. Cache loads can be
detected indirectly, e.g. because they caused some other data to be evicted.
This can potentially work from an entirely different process.
- JITs/interpreters: Easy. Sandbox escape (same-context leak). Shared memory/threads make it easier.
- Same-CPU cross-process: Medium. Attacker needs to trigger the vulnerable code in the vulnerable process, then get a signal from the cache directly (e.g. by timing accesses to memory which has colliding cache tags on the same CPU core or sharing a level of cache). This includes attacks on the kernel and on hypervisors.
- Remote/service: Hard. Attacker needs some way of triggering the vulnerable code, then getting a timing signal back from the relevant cache lines. Probably not practical in most circumstances.
A serialization instruction can be inserted between the condition check and the
read from arr2
in order to force the speculation to be resolved. This may be
microarchitecture-specific in order to make the right guarantees.
A complete fix without manual involvement (e.g. marking security-critical code) seems impractical, short of disallowing all speculative memory accesses entirely. Heuristics such as disallowing speculative memory accesses whose address depends on previously speculatively fetched data will probably fix most (but not all) practical cases.
Compilers may be able to make a better judgement on which code patterns are likely to be dangerous and insert the appropriate serialization instructions.
Google name: Variant 2: Branch target injection
Research name: Spectre
CVE: CVE-2017-5715
The CPU indirect branch predictor can be "trained" to mis-predict an indirect branch into an attacker-controlled destination. This can then leak data via the cache. Chaining multiple gadgets ending in indirect branches, ROP-style, is possible.
This attack requires intimate knowledge of the inner workings of the CPU branch prediction implementation. This does not mitigate the attack, but does make exploitation more difficult (and makes cross-platform attacks much harder).
- JIT: Tricky, but probably possible with careful instruction massaging?
- Same-cpu cross-process: Possible. Includes attacks on the kernel/hypervisor.
- Remote/server: Not possible.
Disable indirect branch prediction entirely by using an alternative instruction sequence. This is microarchitecture-specific. Requires recompiling all code with this sequence.
Flush branch predictor state on privilege level changes and context switches. Causes some performance loss (how much?). Current CPUs do not implement a mechanism to do this this. Hyperthreading makes things more complicated, as two threads of diferent privilege level or isolation may be running on the same CPU and sharing the branch prediction resources. Complete fix may require disabling hyperthreading or introducing OS scheduler changes to ensure that sibling threads are always owned by the same application/user/security context.
Ideally future CPUs would guarantee that hyperthreads have independent branch prediction resources to avoid sharing state, and/or would have efficient methods of isolating branch prediction state (e.g. tagging prediction entries with a process/protection key).
Google name: Variant 3: Rogue data cache load
Research name: Meltdown
CVE: CVE-2017-5754
Some CPUs will perform speculative memory reads from memory that the current context does not have access to read. While these accesses will ultimately fail, their result can be used in further speculation and thus leak. This chiefly allows userspace to read kernel (and thus physical) memory.
- JIT: Possible. Combined with [MISPREDICT], can read arbitrary kernel memory.
- Same-cpu cross-privilege: Easy. Combine with [MISPREDICT] to avoid actual page faults (not required).
- Remote/service: Same as [MISPREDICT] on affected systems. Probably not practical.
This is by far the worst attack on affected systems, as it allows physical memory reads from Javascript on major browsers.
Do not map privileged address space into unprivileged contexts at all. On systems without a functional mechanism to do this without TLB flushing (e.g. PCID) that actually prevents the speculative load, this will incur a significant performance penalty.
ARM name: Variant 3a
A variant of [PRIV-LOAD], where instead of memory, a privileged system register is being read.
- JIT: Not possible.
- Same-cpu cross-privilege: Easy, but limited impact.
- Remote/service: Not possible.
CPU/µArch | MISPREDICT | BTI | PRIV-LOAD | PRIV-REG |
---|---|---|---|---|
i486 | N | N | N | N |
Nehalem | Y?4 | Y1 | Y?4 | |
Westmere | Y?4 | Y1 | Y?4 | |
Sandy Bridge | Y3 | Y1 | Y2 | |
Ivy Bridge | Y3 | Y1 | Y2 | |
Haswell | Y3 | Y1 | Y2 | |
Broadwell | Y3 | Y1 | Y2 | |
Skylake | Y3 | Y1 | Y2 | |
Kaby Lake | Y3 | Y1 | Y2 | |
Coffee Lake | Y3 | Y1 | Y2 | |
Knights Landing | Y?4 | Y1 | Y?4 | |
Knights Mill | Y?4 | Y1 | Y?4 | |
Avoton | Y?4 | Y1 | Y?4 | |
Rangeley | Y?4 | Y1 | Y?4 | |
Apollo Lake | Y?4 | Y1 | Y?4 | |
Denverton | Y?4 | Y1 | Y?4 | |
SoFIA | Y?4 | Y1 | Y?4 | |
Lincroft | Y?4 | Y1 | Y?4 | |
Cloverview | Y?4 | Y1 | Y?4 | |
Bay Trail | Y?4 | Y1 | Y?4 | |
Tunnel Creek | Y?4 | Y1 | Y?4 | |
Stellarton | Y?4 | Y1 | Y?4 |
2: Meltdown paper confirms
[PRIV-LOAD] on Ivy Bridge, Haswell, Skylake. Sibling microarchitectures presumed
vulnerable too.
3: Spectre paper confirms
[MISPREDICT],[BTI] on Ivy Bridge, Haswell, Skylake. Sibling microarchitectures
presumed vulnerable too.
4: Presumed affected since the issues appear to be pervasive to Intel CPUs and
no counterexamples are known yet.
CPU/µArch | MISPREDICT | BTI | PRIV-LOAD | PRIV-REG |
---|---|---|---|---|
Zen (17h) | Y1 | Y?1 | N1 |
See ARM Vendor Response for source.
CPU/µArch | MISPREDICT | BTI | PRIV-LOAD | PRIV-REG |
---|---|---|---|---|
Cortex-R7 | Y | Y | N | N |
Cortex-R8 | Y | Y | N | N |
Cortex-A8 (under review) | Y | Y | N | N |
Cortex-A9 | Y | Y | N | N |
Cortex-A15 (under review) | Y | Y | N | Y |
Cortex-A17 | Y | Y | N | N |
Cortex-A57 | Y | Y | N | Y |
Cortex-A72 | Y | Y | N | Y |
Cortex-A73 | Y | Y | N | N |
Cortex-A75 | Y | Y | Y | N |
All others | N | N | N | N |
Red Hat says System Z, POWER8, POWER9 are affected. No further info.
No info.
No info (CPUs). GPUs not affected.
No info.
No info.
No info.
No info.
Platforms:
- Intel Haswell Xeon
- AMD FX CPU
- AMD PRO CPU
- ARM Cortex A57
Not an actual attack against real software, just a PoC with synthetic code.
Platforms:
- Intel Haswell Xeon CPU
- AMD PRO CPU
A process running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range in kernel virtual memory.
This is an interpreter/JIT attack in the kernel. On Haswell, it works in both JIT and interpreter mode, as the speculation seems to be deep enough to reach even in interpreter mode. On AMD, JIT is required.
Mitigation: AMD: disable eBPF JIT (net.core.bpf_jit_enable
sysctl). Intel:
disable BPF entirely?
Platforms:
- Intel Haswell Xeon CPU
A process running with root privileges inside a KVM guest created using virt-manager, with a specific (now outdated) version of Debian's distro kernel running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization.
Mitigation: None yet. Kernel/compiler patches in the works.
Platforms:
- Intel Haswell Xeon CPU
A process running with normal user privileges can read kernel memory under some precondition, presumed to be that the targeted kernel memory is present in the L1D cache.
Mitigation: KPTI.
Linux kernel page-table isolation. Shipped in Linux 4.14.11 and will ship in 4.15. 4.14.11 version is rough around the edges; future versions should fix further issues.
Still in development.
Kernel assembly mitigation + compiler mitigation (both for kernel and userspace)
that uses a different code sequence (using the ret
instruction) that avoids
the indirect branch predictor on Intel CPUs. Incurs some small performance
impact for every indirect branch. Requires recompiling all affected software
(not just the kernel, but all of userspace) for full mitigation.
This is microarchitecture-specific and thus not necessarily applicable to other
CPUs. Kernel implementation will likely enable it only when a vulnerable CPU is
detected. In fact, it's insufficient on Skylake and newer CPUs, where even ret
may predict from the indirect branch predictor as a fallback; those need IBRS.
Patchset (under review).
Support for Intel's architectural mitigation in lieu of retpolines. Required on Skylake and newer, where even retpolines may be vulnerable. Requires microcode update on current CPUs. Perf hit vs. retpolines on older CPUs. Future CPUs will have "cheap" support.
Out-of-band update. Presumably does roughly the same thing as KPTI.
Some AV software is incompatible (probably due to evil kernel hooks). AV users require this registry key to be set for the fix to be enabled:
Key="HKEY_LOCAL_MACHINE"
Subkey="SOFTWARE\Microsoft\Windows\CurrentVersion\QualityCompat"
Value Name="cadca5fe-87d3-4b96-b7fb-a231484277cc"
Type="REG_DWORD”
Data="0x00000000”
May also contain IBRS support?
PR fluff. No real content. Tries to deflect blame. No useful technical information.
Security advisory. Applies to [BTI]. Contains list of CPU marketing names affected.
- Intel Issues Updates to Protect Systems from Security Exploits
- Intel Analysis of Speculative Execution Side Channels
For [MISPREDICT], recommends an LFENCE
barrier.
For [BTI], Intel is introducing new interfaces to the CPU through microcode:
IBRS
: Indirect Branch Restricted Speculation: Marketing-speak for "we flipped a chicken bit", presumably.STIBP
: Single Thread Indirect Branch Predictors isolates branch prediction state between two hyperthreads.IBPB
: Indirect Branch Predictor Barrier instruction prevents leakage of indirect branch predictor state across contexts (for use on context/privilege switches).
Alternatively, Intel is recommending retpolines for [BPI], especially on current
processors where that may be faster than the microcode patches for IBPB
.
Retpolines also require a microcode patch on Broadwell and newer CPUs,
presumably because on those even ret
ends up being predicted in an exploitable
way.
For [PRIV-LOAD], Intel recommends KPTI. Processors supporting PCID have reduced performance impact. Future CPUs will have a hardware fix.
TODO: further info on microcode updates released.
Claims "near zero" risk for [BTI] but offers no proof. This suggests reliance on obscurity (AMD's branch predictor has not yet been reverse engineered). Assume vulnerable unless proven otherwise.
AMD CPUs are affected by [MISPREDICT] and not affected by [PRIV-LOAD].
TODO: Gentoo bug 643476 claims microcode update to disable branch prediction (entirely?) on family 17h (Zen) is available (SUSE notice). Performance impact unknown.
Comprehensive list of affected ARM CPUs.
For [MISPREDICT], ARM recommends using a newly defined barrier CSDB
together
with a conditional move to guard the loaded value with the preceding condition.
For [BTI] there is no architectural solution, but specific implementations may have branch prediction control features that may allow for mitigation.
For [PRIV-LOAD], there is an Aarch64 implementation of KPTI which uses ASID to isolate the two address spaces, avoiding TLB maintenance overhead.
For [PRIV-REG] the impact is small (KASLR bypass), but can be mitigated by
having the kernel use dummy values or a different virtual base for registers
that might hold virtual kernel addresses while in usermode (e.g. ensure
VBAR_EL1
doesn't leak the true main kernel base).
No response.
GPUs not affected. SoC info and mitigations work in progress. Pending further info.
No response on the CPU side of things for Apple's custom ARM cores.
Enable Site Isolation in chrome://flags
to prevent cross-origin exploitation
of same-process vulns (e.g. JIT).
Starting with Chrome 64, the V8 JS engine will have additional mitigations
(which?). Also SharedArrayBuffer
is being disabled. This makes the attacks
harder (but is not a perfect fix).
Removing SharedArrayBuffer
and reducing resolution of performance.now()
to
20µs. This makes the attacks harder (but is not a perfect fix).
Removing SharedArrayBuffer
and reducing resolution of performance.now()
to
20µs plus random jitter. This makes the attacks harder (but is not a perfect
fix).
Summary:
- Android: 2018-01-05 Security Patch Level mitigates by restricting high precision timers. KPTI not included yet.
- Chrome OS: Version 63 includes KPTI on Intel machines with kernel 3.18/4.4.
- Cloud: Infrastructure has been hitlessly patched. Guest instances for Cloud Dataflow/Cloud Datalab/Cloud Dataproc/Cloud Launcher/Cloud Machine Learning Engine/Compute Engine/Kubernetes Engine need to be updated/restarted with fixes.
Mitigations for [PRIV-READ] shipped in iOS 11.2, macOS 10.13.2, and tvOS 11.2. watchOS is not impacted. Claims no performance impact.
Safari mitigations incoming for [BTI] and [MISPREDICT]. <2.5% perf impact.
[BTI], [PRIV-READ], and [PRIV-REG] are CPU implementation bugs that are easily fixable in newer silicon (with some OS support for [BTI]). [MISPREDICT] is, however, inherent in how modern speculation works, and may change how we have to think about writing secure code in the future, much like how we think about memory races and atomicity in multithreaded code today. In the future, I expect we'll end up seeing speculation guard compiler intrinsics and teaching people to use them.
- Google Project Zero blog post
- Meltdown paper
- Spectre paper
- ARM Processor Security Update
- ARM Cache-speculation Side-channels whitepaper
- AMD Update on Processor Security
- Intel responds to security research findings
- Intel: Speculative Execution and Indirect Branch Prediction Side Channel Analysis Method
- Intel Issues Updates to Protect Systems from Security Exploits
- Intel Analysis of Speculative Execution Side Channels
- Windows 10 KB4056892
- Chrome: Actions Required to Mitigate Speculative Side-Channel Attack Techniques
- Mozilla: Mitigations landing for new class of timing attack
- MS Edge/IE: Mitigating speculative execution side-channel attacks in Microsoft Edge and Internet Explorer
- Google’s Mitigations Against CPU Speculative Execution Attack Methods