Source-linked AI summary
Spectre Attacks: Exploiting Speculative Execution
Paul Kocher, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz, Yuval Yarom
TL;DR
The paper addresses whether speculative execution can undermine security assumptions despite reverting incorrect computations. It develops and demonstrates Spectre attacks that induce transient instructions and recover their effects through microarchitectural side channels, showing that software isolation assumptions are broadly affected and that durable defenses require hardware and ISA changes.
Problem
Speculative execution was assumed to preserve security because incorrect computations are reverted, but the paper examines whether their side effects can nevertheless expose confidential state.
Method
The paper combines branch-predictor mistraining, transient instruction sequences, and microarchitectural covert channels to induce and recover speculative information leaks.
Results
Spectre attacks violate secrecy assumptions across software isolation mechanisms, and the attacks were verified on Intel, AMD, and ARM-based processors.
Takeaways & Limitations
Sound long-term defenses require clear ISA guidance about permitted information exposure and processor implementations that conform to it.
Takeaways & Limitations
Cache-only countermeasures are likely insufficient because speculative execution can leak through memory-bus, DRAM, register, ALU, branch-predictor, power, and electromagnetic effects.
Abstract
from arXiv · showhide
Modern processors use branch prediction and speculative execution to maximize performance. For example, if the destination of a branch depends on a memory value that is in the process of being read, CPUs will try guess the destination and attempt to execute ahead. When the memory value finally arrives, the CPU either discards or commits the speculative computation. Speculative logic is unfaithful in how it executes, can access to the victim's memory and registers, and can perform operations with measurable side effects. Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim's confidential information via a side channel to the adversary. This paper describes practical attacks that combine methodology from side channel attacks, fault attacks, and return-oriented programming that can read arbitrary memory from the victim's process. More broadly, the paper shows that speculative execution implementations violate the security assumptions underpinning numerous software security mechanisms, including operating system process separation, static analysis, containerization, just-in-time (JIT) compilation, and countermeasures to cache timing/side-channel attacks. These attacks represent a serious threat to actual systems, since vulnerable speculative execution capabilities are found in microprocessors from Intel, AMD, and ARM that are used in billions of devices. While makeshift processor-specific countermeasures are possible in some cases, sound solutions will require fixes to processor designs as well as updates to instruction set architectures (ISAs) to give hardware architects and software developers a common understanding as to what computation state CPU implementations are (and are not) permitted to leak.
1 Introduction
The paper introduces Spectre, a class of microarchitectural attacks that exploit speculative execution to leak information through covert channels. It demonstrates practical variants using conditional and indirect branch misprediction across several processor families.
- 1.1 Our Results: Spectre tricks processors into executing transient instruction sequences that should not run, then leaks information from the victim’s memory address space.The nominal CPU state is eventually reverted, but carefully selected transient instructions leave observable microarchitectural effects.
- 1.2 Our Techniques: The attacks combine speculative execution with microarchitectural covert channels, commonly using Flush+Reload or Evict+Reload to recover leaked data.The attacker locates a transmitting instruction sequence, induces its speculative execution, and retrieves information over the covert channel.
- 1.2 Our Techniques: Attackers can exploit conditional branches by training the predictor, supplying an out-of-bounds index, and encoding secret-dependent data in the cache.The cache-state change survives erroneous speculative execution and can be detected to recover a byte of victim memory.
- 1.2 Our Techniques: Indirect-branch attacks train the Branch Target Buffer to redirect speculative execution toward a victim gadget without relying on a vulnerability in victim code.The attacker trains from its own address space using the gadget’s destination virtual address.
- 1.1 Our Results: Spectre attacks were empirically demonstrated on Intel, AMD Ryzen, and several Samsung and Qualcomm processors using ARM architecture.The paper also documents responsible disclosure to multiple CPU vendors and assigns the family CVE-2017-5753 and CVE-2017-5715.
2 Background
The background explains how out-of-order execution, branch prediction, caches, and software-exploitation techniques create performance benefits and observable microarchitectural state. Shared hardware state can allow one program’s behavior to affect another program’s observations.
- Processor Execution: Out-of-order execution increases processor utilization by executing later instructions in parallel with, or before, preceding instructions.Completed instructions are queued and retired in program order, with results becoming externally visible upon retirement.
- Branch Prediction: When a branch depends on unfinished instructions, the processor checkpoints its register state, predicts a path, and speculatively executes along it.A correct prediction allows retirement; an incorrect prediction causes pending instructions to be abandoned while preserving the logical program state.
- Branch Prediction: The Branch Target Buffer predicts future code addresses, while branch-history records help predict whether conditional branches are taken.These structures retain information about recent program behavior to improve speculative execution.
- The Memory Hierarchy: Caches organize memory into fixed-size lines and retrieve data from progressively slower levels after misses, with modern Intel processors using shared and per-core cache levels.A cache miss also brings retrieved data into the faster cache level for possible reuse.
- Microarchitectural Side-Channel Attacks: Changes in shared microarchitectural state can leak information between programs through branch predictors, branch history, and caches.Flush+Reload and Evict+Reload recover information by comparing memory-read timing after cache-line eviction.
- Return-Oriented Programming: Return-Oriented Programming chains machine-code gadgets by placing their addresses on the victim’s stack so each return transfers control to the next gadget.The technique traditionally exploits buffer-overflow vulnerabilities.
3 Attack Overview
A Spectre attack mistrains prediction, induces erroneous speculative execution that transfers confidential data into a microarchitectural side channel, and then recovers the data by measurement. The attack assumes only memory accesses normally permitted to the victim process.
- Attack Overview: Spectre variants induce speculative operations that would not occur during correct execution and leak confidential information through a side channel.The paper considers conditional-branch and indirect-branch misprediction variants.
- Attack Phases: The setup phase mistrains the processor and often evicts a branch-dependent value from the cache to induce speculative execution.The adversary may trigger victim actions through system calls, sockets, or files, or exploit speculative execution within its own process.
- Attack Phases: During the speculative phase, instructions transfer confidential data from the victim context into a microarchitectural side channel.The side-channel effect persists even though the erroneous nominal computation is discarded.
- Attack Phases: The recovery phase times reads from monitored cache lines to infer the secret-dependent state.Flush+Reload and Evict+Reload provide the cache-based measurement mechanism described for these attacks.
- Security Assumptions: Spectre requires only that speculative instructions read memory the victim could normally access without a page fault or exception.This assumption makes Spectre distinct from attacks that rely on speculative access to protected kernel memory.
4 Exploiting Conditional Branch Misprediction
The attack mis trains a bounds check so speculative execution reads an out of bounds secret and encodes it in the cache. Cache measurements then recover the secret despite rollback of the speculative register state.
- The bounds check is intended to prevent out of bounds reads that could access sensitive memory.
- Branch predictor mistraining and a malicious out of bounds x cause speculative execution to follow the incorrect path.
- Speculative execution reads secret byte k through array1[x], then uses k to access array2[k * 256].
- Although the processor rewinds its register state, the speculative array2 read leaves an address specific cache effect dependent on k.
- Cache timing, prime and probe, or flush and probe identifies which array2 entry was loaded and recovers k.
- 10KB/second was achieved on an i7 Surface Pro 3, while the attack also worked across tested Intel, AMD, and ARM processors.
5 Poisoning Indirect Branches
Poisoning indirect branches can redirect speculative execution to attacker-chosen victim-executable gadgets, allowing transient operations to expose victim memory through measurable side effects. Experiments identified predictor behaviors and Windows implementation properties that make this practical, while leaving some platforms and attack targets untested.
- 5 Poisoning Indirect Branches: Mistraining indirect-branch prediction can redirect speculative execution to adversary-chosen locations that would never occur during legitimate execution.This enables attacks even without an exploitable conditional-branch misprediction.
- 5 Poisoning Indirect Branches: Attackers can use victim-executable gadgets that combine attacker-controlled register values, a memory read, and a second memory access to encode chosen victim data.The gadget search is constrained to executable memory available to the victim process.
- 5 Poisoning Indirect Branches: Branch-predictor mistraining can cross hyper-threads and processes on the same CPU, but tests observed no mistraining effects across CPUs.Haswell tests showed cross-hyper-thread effects, while Skylake tests indicated effects between processes on the same vCPU.
- 5 Poisoning Indirect Branches: Shared Windows DLLs provide common virtual-address mappings, megabytes of executable code for gadget searches, and regions suitable for flush-and-probe attacks.DLL modifications use copy-on-write, which can simplify clean gadget returns during mistraining.
- 5 Poisoning Indirect Branches: The predictor appears to use branch-destination virtual addresses and low address bits, while ignoring source address, physical address, timing, and process ID.This can let adversaries compensate for ASLR and avoid executing code at the victim branch’s address.
- 5 Poisoning Indirect Branches: Testing used 32-bit applications on Windows 8; 64-bit modes and other Windows and Linux shared libraries were considered likely to behave similarly, while kernel-mode attacks remained untested.Effects on interrupts and interrupt returns were also unknown.
- 5 Poisoning Indirect Branches: A Windows proof-of-concept completed an attack that read memory from a victim process by using attacker-controlled registers and flush-and-probe.The demonstrated gadget mapped loaded memory values into probeable cache regions.
6 Variations
Spectre variants can use different mechanisms to induce erroneous speculative execution and different microarchitectural effects to leak information. The examples extend beyond cache-based channels to timing and resource-contention effects.
- 6 Variations: Spectre can be combined with microarchitectural attacks that observe cache state or other processor components after speculative execution.The paper examines cache timing, register-file checkpoint contention, instruction timing, and other observable effects.
- 6 Variations: Evict+Time can leak a secret by measuring whether speculative memory activity changes the timing of a subsequent read or creates memory-bus activity.A cache hit and cache miss for the secret-dependent read produce different timing conditions for the second read.
- 6 Variations: Speculative execution can expose information through instruction timing, such as contention for a multiplier whose availability depends on speculative operand processing.This provides a potential channel even when caches are not involved.
- 6 Variations: Finite register-file checkpoint storage can reveal whether a speculative condition created an additional checkpoint when an adversary can detect reduced speculative execution.The example uses contention between speculative executions as the observable effect.
- 6 Variations: Virtually any observable effect of speculatively executed code can serve as a leakage channel, including effects whose timing depends on cache status.The conditional-branch example uses a secret-dependent array access to alter a later observable operation.
7 Mitigation Options
Software and microcode mitigations can reduce some Spectre exploits, but their coverage, portability, and performance remain uncertain. Durable defenses require addressing leakage beyond caches and clarifying processor security guarantees.
- Software Mitigations: Serialization instructions may constrain speculation on some Intel systems, but their architectural behavior does not guarantee that speculation will not leak information.Only cpuid is normally usable in user-mode code and it destroys many registers; mfence and lfence preserve registers but lack defined speculative-execution behavior.
- Software Mitigations: Comprehensive compiler-inserted speculation barriers would severely degrade performance, while protecting only security-critical routines is insufficient because non-security-critical code in the same process can be exploited.Legacy applications would also need recompilation, creating practical deployment challenges.
- Software Mitigations: Indirect branch poisoning is harder to mitigate because disabling hyperthreading or flushing prediction state may lack architectural support and may not cover hazards across shared control-flow constructs.The passage specifically notes possible residual cases in switch statements, interpreters, and parsers.
- Hardware and Microcode: Microcode changes that disable speculation or prevent speculative memory reads may impose significant performance penalties, while the practicality of fixes for existing processors remains unknown.The passage also states that separately buffering speculative memory transactions does not block all timing channels.
- Hardware and Microcode: Cache-only defenses are insufficient because speculative execution can leak through timing effects involving shared resources such as buses or arithmetic units.The passage states that speculative memory transactions need not reach the cache for timing effects to compromise information.
- Long-Term Direction: Software and microcode countermeasures should be treated as stop-gap measures pending further research.The paper frames longer-term mitigation as requiring clearer hardware-software security guarantees.
8 Conclusions and Future Work
The paper finds that Spectre threatens widely deployed software-isolation assumptions, with exploitability varying across processors and victim environments. It therefore calls for clearer ISA guidance and processor implementations that conform to explicit leakage boundaries.
- Conclusions: Speculative execution can violate the secrecy of memory and register contents across software-isolation mechanisms, including sandboxing, process separation, containerization, and memory safety.Existing cache-attack countermeasures that consider only officially executed instructions are also impacted.
- Conclusions: Spectre exploitability depends on the victim CPU, software, compiler choices, and the adversary’s ability to interact with the victim, with same-CPU code execution posing the primary risk.The paper states that some attacks may be straightforward while others depend on register and memory allocation details.
- Conclusions: Because the attacks exploit undocumented hardware effects, a given software program may be exploitable on one processor but not another.The paper gives indirect branch redirection tests that worked on Skylake but not Haswell as an example.
- Future Work: Current stop-gap defenses cannot establish whether a code construction is safe across today’s processors or future designs.This uncertainty follows from processor-dependent exploitability and undocumented speculative behavior.
- Future Work: Long-term solutions require updated instruction set architectures with clear guidance on permitted information exposure and processor implementations that conform to it.The paper presents this as a common understanding required between hardware and software developers.
- Future Work: Spectre reflects a security-performance trade-off created by compounding layers of optimization across processors and software systems.The paper argues that these design choices need to be revisited as insecurity costs rise.
A Spectre Example Implementation
The example implements a Spectre attack by training a bounds-check branch, invoking the victim with a malicious offset, and inferring secret bytes through cache-timing measurements. The x86 demonstration reports guesses using hit scores and a runner-up comparison.
- Platform Setup: The example includes compiler and hardware-specific setup for rdtscp and clflush, plus a delay loop that can also use mfence.The code defines a cache-hit threshold of 80 cycles and includes optimization pragmas.
- Victim Setup: The victim contains a bounds check around array1 access, with secret data and a probe array allocated in memory.The implementation declares array1, array2, a secret string, and a temporary variable used to retain the victim call.
- Cache Encoding: The attack flushes array2 cache lines before each trial so a later cache hit can encode the transiently accessed secret-dependent index.The code uses clflush on array2[i * 512] for all 256 candidate values.
- Branch Training: Each attack run uses 5 training runs for every malicious run, while bit manipulation selects the training or malicious offset without conditional jumps.The code comments state that this avoids jumps that could reveal the branch-predictor manipulation.
- Measurement: The attacker calls the victim with malicious_x, times reads from the probe array, and increments results[mix_i] when a read is a cache hit.The implementation uses rdtscp to measure elapsed time and lightly mixes read order to prevent stride prediction.
- Decoding: The code selects the highest and second-highest result tallies, then reports a successful guess when the best score sufficiently exceeds the runner-up.The stopping condition uses results[j] >= 2 * results[k] + 5 or the 2/0 case; the program labels output as Success when score[0] >= 2*score[1].