PaperlayerView exact revision on arXiv

Source-linked AI summary

Spectre is here to stay: An analysis of side-channels and speculative execution

Ross Mcilroy, Jaroslav Sevcik, Tobias Tebbi, Ben L. Titzer, Toon Verwaest

arXiv:1902.05178v1cs.PLcs.CR

TL;DR

The paper examines how speculative execution and microarchitectural side-channels threaten confidentiality despite programming-language safety mechanisms. It develops models of side-channels and speculative vulnerabilities and analyzes software mitigations; its central conclusion is that speculative vulnerabilities enable a universal read gadget that defeats language-enforced confidentiality, making process isolation necessary.

  • Problem

    Side-channels from shared resources and optimization can compromise confidentiality, while architectural correctness and language-level safety do not account for leaks outside architectural behavior.

    Source: §1 · p. 2, §1.1 · p. 3

  • Method

    The paper develops formal models of microarchitectural side-channels and speculative vulnerabilities, examines attacks, and analyzes software mitigations.

    Source: §1.2 · p. 3, §2.2 · p. 5

  • Results

    Speculative vulnerabilities on today’s CPUs allow a universal read gadget that can read memory through side-channels, defeating language-enforced confidentiality.

    Source: §3.5 · p. 16, §5 · p. 21

  • Takeaways & Limitations

    The paper concludes that hardware/OS process isolation is needed because language mechanisms cannot ensure confidentiality against these vulnerabilities.

    Source: §5 · p. 21

    Timer mitigations are not comprehensive: timer resolution can be recovered, timers are pervasive, shared memory can provide high-resolution timing, and gadgets can be amplified.

    Source: §4.2 · p. 18

Abstract

from arXiv · show

The recent discovery of the Spectre and Meltdown attacks represents a watershed moment not just for the field of Computer Security, but also of Programming Languages. This paper explores speculative side-channel attacks and their implications for programming languages. These attacks leak information through micro-architectural side-channels which we show are not mere bugs, but in fact lie at the foundation of optimization. We identify three open problems, (1) finding side-channels, (2) understanding speculative vulnerabilities, and (3) mitigating them. For (1) we introduce a mathematical meta-model that clarifies the source of side-channels in simulations and CPUs. For (2) we introduce an architectural model with speculative semantics to study recently-discovered vulnerabilities. For (3) we explore and evaluate software mitigations and prove one correct for this model. Our analysis is informed by extensive offensive research and defensive implementation work for V8, the production JavaScript virtual machine in Chrome. Straightforward extensions to model real hardware suggest these vulnerabilities present formidable challenges for effective, efficient mitigation. As a result of our work, we now believe that speculative vulnerabilities on today's hardware defeat all language-enforced confidentiality with no known comprehensive software mitigations, as we have discovered that untrusted code can construct a universal read gadget to read all memory in the same address space through side-channels. In the face of this reality, we have shifted the security model of the Chrome web browser and V8 to process isolation.

1 Introduction

Side-channels arise when implementation behavior, including optimization-dependent timing, reveals information beyond the intended computation. The paper argues that speculative execution challenges programming-language confidentiality and presents models, vulnerability analyses, and mitigation work addressing that threat.

1 Introduction

  • Timing side-channels can arise from optimizations that depend on dynamic values, especially when different parties share system resources.The relevant resources range from processor cores and caches to memory buses and disks.Source: §1 · p. 2

1.1 Security in Programming Languages

  • Programming-language mechanisms can isolate data, but side-channels on architecturally correct yet insecure hardware can undermine language-enforced confidentiality.Memory-safe languages can in principle provide isolation similar to process isolation, placing the burden on the language, compiler, and runtime.Source: §1.1 · p. 3

1.2 A new and pervasive threat

  • Speculative execution can leak data from computations impossible under architectural semantics, putting arbitrary in-memory data at risk.The paper characterizes these vulnerabilities as fundamental microarchitectural design flaws and reports affected products across major vendors.Source: §1.2 · p. 3

1.3 Contributions

  • The paper contributes a formal model of microarchitectural side-channels and optimizations, plus an amplification technique that makes small timing differences detectable with any-resolution clocks.It also presents a formal model explaining classes of speculative vulnerabilities.Source: §1.3 · p. 4
  • The paper describes and constructs the universal read gadget, and analyzes exploitable source-language features that can enable it.The gadget is the ultimate leak from speculation identified by the paper.Source: §1.3 · p. 4
  • The paper formally analyzes mitigations for variant 1 and discusses mitigations for other speculative-vulnerability variants.Source: §1.3 · p. 4

2 Understanding microarchitectural side-channels

The section models how hidden microarchitectural state can carry information despite unchanged architectural state. It then shows how timing can expose that information, including when clock resolution is too low to observe it directly.

2 Understanding microarchitectural side-channels

  • A simulation relation connects architectural states to potentially many microarchitectural states, whose extra hidden state can create side-channels even in deterministic systems.The model applies to general state-transition systems, not only CPUs; its scope assumes countable program and state sets.Source: §2 · pp. 4–5

2.1 Writing information into µ-state

  • A write mechanism encodes an input bit in distinct microarchitectural states while both inputs converge to the same observable architectural state.A function over the resulting microarchitectural states can recover the bit.Source: §2.1 · p. 5

2.2 Reading information from µ-state

  • A read mechanism measures hidden state directly or through microarchitectural event counters, breaking the abstraction that otherwise keeps the encoded information inaccessible.Clocks are modeled as monotonically increasing functions of execution steps with bounded drift.Source: §2.2 · pp. 5–6

2.3 A timing channel that exploits optimizations

  • A timing channel arises when an optimization trigger changes µ-state and a later optimization opportunity runs faster or slower, letting a clock reveal the difference.The programs can have no visible architectural divergence based on their input.Source: §2.3 · p. 6

2.4 Amplification Lemma

  • Repeating trigger–opportunity pairs accumulates sub-resolution timing differences until a single clock reading can distinguish the encoded bit.The amplification program takes the same number of architectural steps for either input; the argument relies on knowing the clock rate and drift bound.Source: §2.4 · p. 7
  • Timer manipulation cannot completely mitigate timing channels in this model: coarsening lowers bandwidth, while charging back saved time erodes optimization benefits.The authors suggest constant-time implementations may be the only way to avoid timing leaks.Source: §2.4 · p. 7

3 An Architecture to study Spectre

The paper builds an architectural semantics and adds microarchitectural state to model speculative execution and timing. The model captures caches, branch prediction, indirect-branch prediction, and control speculation, while excluding multicore systems, threads, pipelines, and memory barriers.

3 An Architecture to study Spectre

  • The model excludes multicore systems, threads, pipelines, and memory barriers while adding microarchitectural state to study speculative vulnerabilities.Its base architecture represents programs as indexed instructions and architectural state as a program counter, registers, and memory.Source: §3 · p. 8

3.1.1 Modeling memory caches

  • Loads and stores add accessed addresses to a bounded cache, with uncached accesses requiring an extra micro-step.The cache uses LRU replacement; the paper notes that the exact replacement algorithm is mostly orthogonal to this work.Source: §3.1.1 · pp. 8–9, §3.1.4 · p. 9

3.1.2 Branch Predictor State

  • Branch-predictor state records program-counter and prediction pairs, updated after the branch outcome is known.The model also maintains an indirect-branch target table that is updated after each jump executes.Source: §3.1.2 · p. 9, §3.1.3 · p. 9

3.1.4 Modeling Control Speculation

  • Control speculation uses a reorder buffer: branches can be predicted before their conditions are available, and a failed prediction flushes the buffer at commit.Instructions execute out of order once dependencies are available; commits apply the oldest buffered instruction to architectural state.Source: §3.1.4 · pp. 9–10
  • The model defines mis-speculation as a branch prediction that disagrees with the condition evaluated from the buffered instructions.The theorem states that a reachable state either agrees with the microarchitectural state at every buffer depth or mis-speculates at some depth.Source: §3.1.4 · p. 11

3.1.5 Timer

  • A timer counts microarchitectural steps, and a timer-read instruction returns the count in a register.The semantics increments the timer on every evaluation step.Source: §3.1.5 · p. 11

3.2 Composing µ-architectural extensions

The paper composes its microarchitectural extensions into a larger model. Because most extensions have orthogonal state, composition is generally straightforward, though potentially tedious.

3.2 Composing µ-architectural extensions

  • A combined model can include caches, branch predictors, indirect-branch predictors, out-of-order execution, and a timer.Most extensions have orthogonal state, so composition is generally straightforward but may be tedious.Source: §3.2 · p. 12

3.3 Cache-based side-channels

The model treats a cache as a source of meta-information about program history, while acknowledging that real caches have additional details it omits. The paper describes two ways to encode and retrieve information through cachedness, with different costs and robustness to errors.

3.3 Cache-based side-channels

  • The cache model is simplified relative to real CPU caches, which include physical-data copies, tags, dirtiness and coherency state, and multiple levels.The paper says these details are not needed for its model, without specifying the unfinished scope in this passage.Source: §3.3 · p. 12

3.3.1 Encoding information in cachedness

  • A cache's meta-information capacity represents information about program history and depends on microarchitectural details; decoding limits practical capacity below the model's theoretical value.The model expresses this capacity as Cinfo = Cmax log |M|, where Cmax is cache capacity and |M| is the maximum memory address.Source: §3.3.1 · p. 13
  • Cachedness encodings must withstand intervening memory accesses, accesses caused by retrieval itself, and noise from interrupts or concurrent processes sharing the cache.These sources of interference motivate encoding schemes designed to preserve information between storage and retrieval.Source: §3.3.1 · p. 13
  • Direct-mapped bits trade space efficiency for one access per bit written, while indexed values write multiple bits with one access but require 2^b probes to read them.Indexed values are more robust to incidental eviction; the authors typically used them with 4 ≤ b ≤ 8 on real hardware.Source: §3.3.1 · p. 13

3.4 Vulnerabilities by the Numbers

Speculative execution can bypass software safety checks because architectural rollback does not undo microarchitectural changes. The section shows both bounds-check bypass and indirect-branch target misreconstruction can expose secrets through those changes.

3.4.1 Variant 1: Speculative Safety Check Bypass

  • The first variant exploits safety-check branches that usually pass, then triggers a misprediction so code executes speculatively without the established safety condition.Normal recovery restores architectural state, but does not undo microarchitectural changes such as cache updates.Source: §3.4.1 · p. 13
  • A trained predictor can bypass a bounds check, speculatively load an out-of-bounds secret, encode it in cache state, and let timing reveal it.Architectural execution rolls back to the out-of-bounds handler, but the cache change remains.Source: §3.4.1 · pp. 13–14
  • Indirect-branch speculation can violate virtual-dispatch type assumptions: a predicted method for type A may run on a type B object and interpret its integer field as a pointer.The attacker can craft that field to point at a secret, which is then exfiltrated through cache state.Source: §3.4.1 · pp. 14–15

3.4.2 Variant 2: Speculative Target Misreconstruction

  • Approximate branch-target prediction can redirect a victim indirect branch to attacker-chosen code within a 4GiB range without executing the victim branch during training.The predictor aliases branches by storing only low-order address bits; the resulting speculative control flow can enter an existing leaking gadget and can cross processes.Source: §3.4.2 · p. 15

Appendix A.1 provides an illustrative example of a variant 2 attack.

Hardware permission checks and speculative memory disambiguation can both expose data before a fault or ordering violation is resolved. In each case, stale or otherwise forbidden values may reach speculative execution.

3.4.3 Variant 3: Speculative Hardware Permission Check Bypass

  • If a CPU checks a memory fault too late, a userspace process may speculatively consume and leak kernel data; lazy FPU state restore can similarly expose a previous process’s stale register value.The timing depends on CPU trap behavior: a fault at retirement is too late if the value has already reached dependent instructions and microarchitectural state.Source: §3.4.3 · p. 16

3.4.4 Variant 4: Speculative Aliasing Confusion

  • A memory disambiguator may speculatively execute a load before an aliased store, so the load observes a stale value before the ordering violation is detected and repaired.Other speculative forwarding strategies can also be used; their behavior depends on implementation details.Source: §3.4.4 · p. 16

Appendix A.2 provides an illustrative example of a variant 4 attack.

The section names the universal read gadget: speculative vulnerabilities can let a well-typed procedure use a microarchitectural side channel to read process memory. It identifies vulnerable language features and notes practical constraints on constructing and running such a gadget.

3.5 The Universal Read Gadget

  • A universal read gadget can read addressable process memory through a microarchitectural side channel, although misspeculated execution has no architectural side effects.The paper describes this as a general out-of-bounds read and says the procedure can be well-typed.Source: §3.5 · p. 16
  • Gadget construction requires detailed knowledge of CPU microarchitecture and language implementation, and may need timer amplification, predictor warmup, or repeated attempts under noise.The authors focused on in-process attacks; variant 4 can be difficult to exploit reliably, while variant 1 was relatively simple to exploit.Source: §3.5 · pp. 17–18
  • Speculative pointer crafting is central: attacker-controlled input is interpreted as a machine-level pointer and fed to a load that is dangerous only during speculation.The paper says access to a timer, regardless of resolution, leaks microarchitectural information.Source: §3.5 · p. 17
  • Vulnerable language features include dynamic bounds checks, differing object layouts, dynamically shaped structures, variadic arguments, interpreter dispatch, indirect control transfers, call stacks, and jump-table switches.These mechanisms can enable speculative out-of-bounds access, type confusion, or pointer crafting.Source: §3.5 · p. 17
  • Return-address prediction and jump-table switch statements are additional pointer-crafting paths through mispredicted control flow.The paper links these respectively to the return address stack and the indirect branch predictor.Source: §3.5 · p. 17

4 Mitigations

The paper evaluates software mitigations that trade performance for incomplete protection against speculative attacks. V8 mitigation work led Chrome to shift its defense to site isolation.

4.1 Disabling Speculation

  • LFENCE limits speculative loads locally, but variant 2 can skip inserted fences, variant 4 may require fencing every load, and broad use can slow execution by orders of magnitude.Its microarchitectural effects are proprietary and cannot be audited; the instruction was designed as a memory-load barrier, not a speculation barrier.Source: §4.1 · p. 18

4.2 Timer Mitigation

  • Timer reduction is not comprehensive: resolution recovery, pervasive timers, shared-memory timers, and gadget amplification can restore usable timing differences.The Amplification Lemma shows gadgets can be amplified to arbitrary timing differences.Source: §4.2 · p. 18

4.3.1 Array index masking

  • Because branch prediction can bypass branch-based safety checks, array index masking adds arithmetic that clamps out-of-bounds indices to 0, including during misspeculation.The inserted multiplication is a no-op on the architected path, adding overhead and risking removal by an optimizing compiler.Source: §4.3 · p. 18, §4.3.1 · p. 19

4.3.2 Pervasive conditional masking

  • Pervasive conditional masking tracks speculative safety in a poison register and masks load addresses with that value.A proof shows that, assuming address 0 is not secret, a load after a mis-speculated branch reads address 0 instead of its target.Source: §4.3.2 · p. 19

4.3.3 Pervasive indirect branch masking

  • Indirect-branch masking compares each potential target with the expected target and updates the poison register, but covers only variant 1 attacks.A variant 2 attacker can train an indirect branch to alias with an uninstrumented location, bypassing the poison computation.Source: §4.3.3 · p. 20

4.4 Mitigating Other Mispredictions

  • Retpoline avoids indirect branches to block branch-target-buffer predictions, but relies on Intel’s return-stack-buffer priority and does not work on other CPU models or architectures.Variant 4 can expose wrong speculative load values; the paper reports no known software mitigation for that behavior.Source: §4.4 · p. 20

4.5 Implementation in a Production JavaScript VM

  • On Octane, LFENCE slowed 2.8x, retpoline 1.52x, array masking 10%, and conditional poisoning 19%.Pervasive indirect masking had negligible overhead with V8 optimization enabled and a 12% slowdown with it disabled; a subset of mitigations shipped, but Chrome shifted to site isolation.Source: §4.5 · pp. 20–21

5 Conclusion

Spectre undermines language-enforced confidentiality through speculative side-channels, and the paper concludes that process isolation is needed. Finding, understanding, and mitigating these vulnerabilities remain open problems.

5 Conclusion

  • The authors report that untrusted code can construct a universal read gadget, defeating language-enforced confidentiality in the same address space.They argue that hardware/OS process isolation is needed and that no comprehensive software mitigation is known.Source: §5 · p. 21
  • Finding microarchitectural side-channels requires enumerating and modeling relevant state, which is difficult on closed-source processors.Source: §5 · p. 21
  • Understanding vulnerabilities requires modeling how programs manipulate and observe microarchitectural state, including complex state in black-box processors.Source: §5 · p. 21
  • Efficient software mitigations for existing hardware remain in their infancy, while hardware mitigation for future designs remains an open design problem.The paper links these challenges to systems complexity and performance-driven design.Source: §5 · pp. 21–22

A.1 Variant 2: Illustrative Example

The example shows how variant 2 target misreconstruction can direct speculative execution into an attacker-controlled routine that leaks secret data through the cache.

A.1 Variant 2: Illustrative Example

  • A predictor that stores only the lower 2 source-address bits and encodes targets as offsets can confuse an intended indirect jump with an attacker-positioned target, executing a speculative secret-reading gadget.The attack routine loads an attacker-crafted pointer and encodes the resulting value in the cache.Source: §A.1 · p. 24

A.2 Variant 4: Illustrative Example

The example illustrates variant 4 speculative aliasing confusion: a memory location reused for arguments of different types can be read before a store completes, allowing an attacker-controlled integer to be treated as a pointer.

A.2 Variant 4: Illustrative Example

  • The attacker trains memory disambiguation with an integer argument, then replaces it with an object pointer; a misprediction lets the load run before the store completes and treat the integer as a pointer.The resulting speculative load can access secret memory and encode its state in a timing array.Source: §A.2 · p. 24
Loading 1902.05178v1…