Swivel: Hardening WebAssembly against Spectre Shravan Narayan† Craig Disselkoen† Daniel Moghimi¶† Sunjay Cauligi† Evan Johnson† Zhao Gang† Anjo Vahldiek-Oberwagner? Ravi Sahita∗ Hovav Shacham‡ Dean Tullsen† Deian Stefan† †UC San Diego ¶Worcester Polytechnic Institute ?Intel Labs ∗Intel ‡UT Austin Abstract in recent microarchitectures [41] (see Section 6.2). In con- We describe Swivel, a new compiler framework for hardening trast, Spectre can allow attackers to bypass Wasm’s isolation WebAssembly (Wasm) against Spectre attacks. Outside the boundary on almost all superscalar CPUs [3, 4, 35]—and, browser, Wasm has become a popular lightweight, in-process unfortunately, current mitigations for Spectre cannot be im- sandbox and is, for example, used in production to isolate plemented entirely in hardware [5, 13, 43, 51, 59, 76, 81, 93]. different clients on edge clouds and function-as-a-service On multi-tenant serverless, edge-cloud, and function as a platforms. Unfortunately, Spectre attacks can bypass Wasm’s service (FaaS) platforms, where Wasm is used as the way to isolation guarantees. Swivel hardens Wasm against this class isolate mutually distursting tenants, this is particulary con- 1 of attacks by ensuring that potentially malicious code can nei- cerning: A malicious tenant can use Spectre to break out of ther use Spectre attacks to break out of the Wasm sandbox nor the sandbox and read another tenant’s secrets in two steps coerce victim code—another Wasm client or the embedding (§5.4). First, they mistrain different components of the under- process—to leak secret data. lying control flow prediction—the conditional branch predic- We describe two Swivel designs, a software-only approach tor (CBP), branch target buffer (BTB), or return stack buffer that can be used on existing CPUs, and a hardware-assisted (RSB)—to speculatively execute code that accesses data out- approach that uses extension available in Intel® 11th genera- side the sandbox boundary. Then, they reconstruct the secret tion CPUs. For both, we evaluate a randomized approach that data from the underlying microarchitectural state (typically mitigates Spectre and a deterministic approach that eliminates the cache) using a side channel (cache timing). Spectre altogether. Our randomized implementations impose One way to mitigate such Spectre-based sandbox breakout under 10.3% overhead on the Wasm-compatible subset of attacks is to partition mutually distrusting code into separate SPEC 2006, while our deterministic implementations impose processes. By placing untrusted code in a separate process overheads between 3.3% and 240.2%. Though high on some we can ensure that the attacker cannot access secrets. Chrome benchmarks, Swivel’s overhead is still between 9× and 36.3× and Firefox, for example, do this by partitioning different sites smaller than existing defenses that rely on pipeline fences. into separate processes [25, 64, 68]. On a FaaS platform, we could similarly place tenants in separate processes. 1 Introduction Unfortunately, this would still leave tenants vulnerable to WebAssembly (Wasm) is a portable bytecode originally de- cross-process sandbox poisoning attacks [12, 36, 50]. Specif- signed to safely run native code (e.g., C/C++ and Rust) in ically, attackers can poison hardware predictors to coerce a the browser [27]. Since its initial design, though, Wasm has victim sandbox to speculatively execute gadgets that access been increasingly used to sandbox untrusted code outside the secret data—from their own memory region—and leak it via browser. For example, Fastly and Cloudflare use Wasm to the cache (e.g., by branching on the secret). Moreover, using sandbox client applications running on their edge clouds— process isolation would sacrifice Wasm’s scalability (running where multiple client applications run within a single pro- many sandboxes within a process) and performance (cheap cess [30, 85]. Mozilla uses Wasm to sandbox third-party startup times and context switching) [28, 30, 65, 85]. C/C++ libraries in Firefox [21, 65]. Yet others use Wasm to The other popular approach, removing speculation within isolate untrusted code in serverless computing [28], IoT appli- the sandbox, is also unsatisfactory. For example, using cations [10], games [62], trusted execution environments [17], pipeline fences to restrict Wasm code to sequential execution and even OS kernels [79]. imposes a 1.8×–7.3× slowdown on SPEC 2006 (§5). Con- In this paper, we focus on hardening Wasm against Spec- servatively inserting pipeline fences before every dynamic tre attacks—the class of transient execution attacks which load—an approach inspired by the mitigation available in exploit control flow predictors [49]. Transient execution at- Microsoft’s Visual Studio compiler [61]—is even worse: it tacks which exploit features within the memory subsystem incurs a 7.3×–19.6× overhead on SPEC (§5). (e.g., Meltdown [57], MDS [11, 72, 84], and Load Value In- 1Though our techniques are general, for simplicity we henceforth focus jection [83]) are limited in scope and have already been fixed on Wasm as used on FaaS platforms. In this paper, we take a compiler-based approach to hard- To eliminate host poisoning attacks, we use both Intel® ening Wasm against Spectre, without resorting to process CET and Intel® MPK. In particular, we use Intel® MPK to par- isolation or the use of fences. Our framework, Swivel, ad- tition the application into two domains—the host and Wasm dresses not only sandbox breakout and sandbox poisoning sandbox(es)—and, on context switch, ensure that each domain attacks, but also host poisoning attacks, i.e., Spectre attacks can only access its own memory regions. We use Intel® CET that coerce the process hosting the Wasm sandboxes into leak- forward-edge control-flow integrity to ensure that application ing sensitive data. That is, Swivel ensures that a malicious code cannot jump, sequentially or speculatively, into arbitrary Wasm tenant cannot speculatively access data outside their sandbox code (e.g., due to a poisoned BTB). We do this by sandbox nor coerce another tenant or the host to divulge se- inserting endbranch instructions in Wasm sandboxes to de- crets of other sandboxes via poisoning. We develop Swivel marcate valid jump targets, essentially partitioning the BTB via three contributions: into two domains. Our use of Intel’s MPK and CET ensures that even if the host code runs with poisoned predictors, it 1. Software-only Spectre hardening (§3.2) Our first con- cannot read—and thus leak—sandbox data. tribution, Swivel-SFI, is a software-only approach to harden- ® ing Wasm against Spectre. Swivel-SFI eliminates sandbox Since Intel MPK only supports 16 protection regions, we breakout attacks by compiling Wasm code to linear blocks cannot use it to similarly prevent sandbox poisoning attacks: (LBs). Linear blocks are straight-line x86 code blocks that serverless, edge-cloud, and FaaS platforms have thousands satisfy two invariants: (1) all transfers of control, including of co-located tenants. Hence, to address sandbox poisoning function calls, are at the block boundary—to (and from) other attacks, like for Swivel-SFI, we consider and evaluate two linear blocks; and (2) all memory accesses within a linear designs. The first (again) uses ASLR to randomize the loca- block are masked to the sandbox memory. These invariants tion of each sandbox and flushes the BTB on sandbox entry; are necessary to ensure that the speculative control and data we don’t flush on sandbox exit since the host can safely run flow of the Wasm code is restricted to the sandbox boundary. with a poisoned BTB. The second is deterministic and not They are not sufficient though: Swivel-SFI must also be tol- only allows using conditional branches but also avoids BTB erant of possible RSB underflow. We address this by (1) not flushes. It does this using a new technique, register interlock- emitting ret instructions and therefore completely bypassing ing, which tracks the control flow of the Wasm sandbox and the RSB and (2) using a separate stack for return addresses. turns every misspeculated memory access into an access to To address poisoning attacks, Swivel-SFI must still account an empty guard page. Register interlocking allows a tenant for a poisoned BTB or CBP. Since these attacks are more so- to run with a poisoned BTB or CBP since any potentially phisticated, we evaluate two different ways of addressing poisoned speculative memory accesses will be invalidated. them, and allow tenants to choose between them according to their trust model. The first approach uses address space 3. Implementation and evaluation (§4–5) We implement layout randomization (ASLR) to randomize the placement of both Swivel-SFI and Swivel-CET by modifying the Lucet each Wasm sandbox and flushes the BTB on each sandbox compiler’s Wasm-to-x86 code generator (Cranelift) and run- boundary crossing. This does not eliminate poisoning attacks; time. To evaluate Swivel’s security we implement proof of it only raises the bar of Wasm isolation to that of process iso- concept breakout and poisoning attacks against stock Lucet lation. Alternately, tenants can opt to eliminate these attacks (mitigated by Swivel). We do this for all three Spectre variants, altogether; to this end, our deterministic Swivel-SFI rewrites i.e., Spectre attacks that abuse the CBP, BTB, and RSB. conditional branches to indirect jumps—thereby completely We evaluate Swivel’s performance against stock Lucet and bypassing the CBP (which cannot be directly flushed) and several fence-insertion techniques on several standard bench- relying solely on the BTB (which can). marks. On the Wasm compatible subset of the SPEC 2006 2. Hardware-assisted Spectre hardening (§3.3) Our sec- CPU benchmarking suite we find the ASLR variants of ond contribution, Swivel-CET, restores the use of all predic- Swivel-SFI and Swivel-CET impose little overhead—they tors, including the RSB and CBP, and partially obviates the are at most 10.3% and 6.1% slower than Lucet, respectively.