Swivel: Spectre-hardening for WebAssembly

• Swivel is a compiler-based framework that hardens Wasm modules against Spectre attacks using static analysis and hardware features.
• It employs Linear Blocks for strict control-flow and memory safety, leveraging CET, MPK, and shadow stacks to mitigate speculative execution.
• Swivel offers software-only and hardware-assisted modes, balancing robust security with performance trade-offs and minimal overhead.

Swivel is a compiler-based framework designed to harden WebAssembly (Wasm) modules against the full spectrum of Spectre attacks, particularly including Spectre 1.1 and 1.2 variants which exploit speculative stores and speculative overwrites of read-only data. Swivel systematically employs program transformation and, in hardware-assisted modes, processor features such as Control-flow Enforcement Technology (CET) and Memory Protection Keys (MPK), to provide comprehensive sandboxing that restricts speculative control and data flow, maintaining strong isolation without resorting to pervasive pipeline fences or process isolation. By coordinating static analysis, fine-grained code instrumentation, and hardware primitives, Swivel achieves robust, end-to-end Spectre hardening for Wasm runtimes, with measured overheads substantially lower than fence-based or ad hoc mitigations (Narayan et al., 2021, Kiriansky et al., 2018).

1. Threat Model and Spectre Variants Addressed

Swivel is constructed to defend programs from all three principal Spectre attack classes: Spectre-PHT (branch predictor poisoning), Spectre-BTB (branch target buffer collision), and Spectre-RSB (return stack buffer manipulation). The framework’s focus is to prevent sandbox breakout by adversarial Wasm code, cross-module branch predictor poisoning, and secrets leakage from both the Wasm sandbox and the embedding native host. Swivel's design explicitly targets speculative buffer overflows and speculative store-based attacks (Spectre 1.1), as well as speculative store-to-read-only (Spectre 1.2), by enforcing strong intra-module and cross-module control- and data-flow restrictions under speculation (Narayan et al., 2021, Kiriansky et al., 2018).

2. Architectural Principles and Linear Block Discipline

The central abstraction in Swivel is the Linear Block (LB). An LB is a straight-line segment of native code with control-flow transfers only permitted at its boundaries. Swivel’s compiler pass ensures that both architectural and speculative execution cannot transfer into the middle of an LB; transition mechanisms such as explicit jump markers or indirect branch tracking (IBT endbranch instructions in CET-capable hardware) demarcate LBs, confining all effects—speculative or otherwise—to single blocks.

Memory access safety within each LB is ensured by reserving (“pinning”) a dedicated register to hold the sandbox heap base, with every memory operation locally masked via Speculative Load Hardening. This pattern enforces data locality, preventing attacks that might use mis-speculated indices to perform out-of-bounds loads or stores. Returns are systematically guarded: under software-only deployment, return addresses are stored in guarded memory and never accessed with a raw ret, while hardware-assisted deployments leverage CET's shadow stack.

3. Swivel Deployment Modes: Software-Only and Hardware-Assisted

Swivel offers two complementary implementations:

• Software-only ($\Swivel_{SFI}$): This mode relies solely on compiler-based program rewriting. It inserts SFI-style guards, leverages a custom software shadow stack, and flushes the BTB upon every entry to the Wasm sandbox. No hardware requirements are imposed, allowing deployment on any superscalar CPU. Bound-check masking and safe sandbox boundary management block Spectre vectors, but this approach requires hyperthreading to be disabled due to the risk of sibling-thread BTB sharing.
• Hardware-assisted ($\Swivel_{CET}$): This variant expects Intel 11th-gen (Tiger Lake) or newer CPUs with CET and MPK. It employs the hardware shadow stack for RSB protection and IBT for forward-edge CFI, eliminating the need for software shadow stack and BTB flushes at intra-sandbox breaks. MPK domains separate host and sandbox memory, blocking speculative faults from leaking host secrets. This configuration is robust even with SMT enabled.

Compiler transformation for each approach ensures that all conditional branches are either instrumented for control-flow integrity or directly eliminated by instruction substitution, with finer grain under —and greater reliance on—the available hardware feature set (Narayan et al., 2021).

4. Mitigation Strategies: Randomized versus Deterministic

Swivel provides two major classes of mitigation within both software-only and hardware-assisted modes:

• Randomized (“ASLR”) Mode: Each Wasm module is loaded at a random offset with at least 26 bits of entropy (16-byte alignment in the 32-bit address space). This randomization applies to all cross-module or host boundary transitions. The probability of successful Spectre-PHT or Spectre-BTB poisoning is reduced to at most $\frac{n}{2^{26}}$, where $n$ is the number of congruent attacker-controlled branches. In software-only mode, the BTB is flushed at every sandbox entry; under hardware-assistance, ASLR is sufficient within the limits of the hardware predictor partitioning.
• Deterministic Mode: Conditional branches are rewritten to avoid predictor usage; for example, if-then-else conditions are transformed into conditional moves, preventing speculative execution from using the pattern-history table (PHT). Cross-sandbox BTB pollution is defeated by explicit BTB flush ($\Swivel_{SFI}$) or register interlock ($\Swivel_{CET}$): LB entry is tagged with a label, and memory accesses are data-dependent on this label, causing fault (guard pages) if speculation enters an unauthorized block. Spectre-RSB is rendered inert by the shadow stack (software or hardware). In deterministic mode, the probability of Spectre violation is zero.

5. Coverage of Spectre Vectors and Security Guarantees

Swivel systematically prevents:

• Sandbox Breakout: LB boundaries and local bounds-check masking combine to thwart in-place, same-module breakout via speculative buffer overflows or stores.
• Sandbox Poisoning: ASLR and BTB flush greatly limit, and in deterministic mode eliminate, cross-module branch-poisoning attacks.
• Host Poisoning: In software-only mode, BTB flush and ASLR strongly isolate the host’s BTB/CBP state from the sandbox; in hardware-assisted mode, MPK ensures host memory inaccessibility, even speculatively.

Explicit protection of the return address (by software or CET shadow stack) and mandatory masking of all pointers using both the heap-base and bounds-checked index ensures that speculative stores or loads cannot corrupt or observe host or other tenant memory, even in the presence of microarchitectural side channels (Narayan et al., 2021, Kiriansky et al., 2018).

6. Performance and Cost Analysis

The following table summarizes the observed performance overheads for various Swivel protection modes as measured on the Lucet Wasm runtime executing the SPEC 2006 integer subset:

Mitigation	Maximum Slowdown	Geometric Mean	Notes
$\Swivel_{SFI}$–ASLR	$10.3\times$	$3.4\times$	Software-only, compatible CPUs
$\Swivel_{SFI}$–det.	$\Swivel_{CET}$0–$\Swivel_{CET}$1	$\Swivel_{CET}$2	Deterministic, highest overhead
$\Swivel_{CET}$3–ASLR	$\Swivel_{CET}$4	$\Swivel_{CET}$5	Requires Intel CET+MPK
$\Swivel_{CET}$6–det.	$\Swivel_{CET}$7–$\Swivel_{CET}$8	$\Swivel_{CET}$9	Deterministic, very high cost
LoadLfence	$\frac{n}{2^{26}}$0–$\frac{n}{2^{26}}$1	–	One lfence after every load
Strawman	$\frac{n}{2^{26}}$2–$\frac{n}{2^{26}}$3	–	One lfence per linear block
Mincut	$\frac{n}{2^{26}}$4–$\frac{n}{2^{26}}$5	–	Optimized fence placement

The randomized Swivel variants ($\frac{n}{2^{26}}$6–ASLR, $\frac{n}{2^{26}}$7–ASLR) preserve most of the baseline Wasm performance, far outperforming naive fence-based mitigations both in slowdown and in preservation of baseline execution speed (Narayan et al., 2021).

7. Integration with Hardware Mechanisms and Comparison to SLoth

Swivel is contrasted with the “SLoth” family of hardware-centric Spectre 1.1/1.2 defenses (Kiriansky et al., 2018). Whereas Swivel’s static analysis and compiler pass insert speculation barriers or index masking via software analysis, SLoth introduces microarchitectural controls for speculative store-to-load forwarding (e.g., SLoth Bear, SLoth with compiler-directed forwarding, and Arctic SLoth with pair-wise whitelisting). Both approaches share the goal of breaking store-to-load confusion, but with different strengths:

• Swivel must over-approximate vulnerable code sites, risking either missed gadgets or excessive barriers. SLoth’s hardware/microcode enforces safety even if some patterns are missed.
• Swivel’s fine-grained static analysis could be paired with SLoth’s hint bits (Lazy SLoth), exploiting compiler knowledge to precisely tag stores/loads that may be safely forwarded.
• Integrated, these approaches permit hardware-level guarantees with minimal power/performance cost and maximal code coverage: Swivel marks the forwarding rights, while SLoth enforces them architecturally.

A plausible implication is that Swivel, layered atop hardware features as in SLoth, enables highly granular, high-performance Spectre protection incorporating both static and dynamic approaches.

8. Limitations and Practical Considerations

Swivel's software-only modes require hyperthreading to be disabled due to possible cross-thread BTB sharing. Deterministic modes yield strong guarantees but incur substantial overhead in loop-heavy workloads, especially when iteration dependencies prevent aggressive optimization. Swivel addresses only Spectre-class vulnerabilities; attacks such as Meltdown/MDS/LVI are expected to be mitigated in underlying microcode or by orthogonal techniques, e.g., SSBD.

No formal security theorem is given, but argumentation centers on the level of entropy in ASLR and the data-dependence or control-flow rewrites that drive the success probability of prediction-based attacks arbitrarily close to zero as justified by:

$\frac{n}{2^{26}}$8

$\frac{n}{2^{26}}$9

where $n$0 is the attacker's degree of control and $n$1 is the entropy provided by randomization.

Deployment is practical and modular: Swivel's software-only and hardware-assisted variants can coexist, enabling tenants and platform operators to select the appropriate trade-off between performance overhead and strength of isolation (Narayan et al., 2021).

---

Swivel represents a comprehensive, transparent Spectre-hardening framework for Wasm environments, synthesizing static software hardening and hardware primitives in a manner that is extensible, performant, and broadly applicable, with designs and performance characteristics substantially documented by the Lucet/Cranelift and SLoth research efforts (Narayan et al., 2021, Kiriansky et al., 2018).