Table of Contents
Fetching ...

Cage: Hardware-Accelerated Safe WebAssembly

Martin Fink, Dimitrios Stavrakakis, Dennis Sprokholt, Soham Chakraborty, Jan-Erik Ekberg, Pramod Bhatotia

TL;DR

Cage presents a hardware-accelerated toolchain that adds memory safety and improved sandboxing to unmodified $64$-bit WebAssembly programs on ARM, by leveraging MTE and PAC. It introduces a minimal WASM extension with segment-based memory tagging and pointer authentication, integrates an LLVM toolchain and a modified wasi-libc, and implements the safety features in wasmtime. Empirically, Cage achieves low runtime and memory overheads while delivering strong external and internal memory safety guarantees, and it substantially speeds up sandboxing compared to software-only approaches. The work demonstrates that hardware-assisted memory safety for WASM is viable in production settings and offers practical defense-in-depth against memory-safety exploits and cross-instance pointer leakage.

Abstract

WebAssembly (WASM) is an immensely versatile and increasingly popular compilation target. It executes applications written in several languages (e.g., C/C++) with near-native performance in various domains (e.g., mobile, edge, cloud). Despite WASM's sandboxing feature, which isolates applications from other instances and the host platform, WASM does not inherently provide any memory safety guarantees for applications written in low-level, unsafe languages. To this end, we propose Cage, a hardware-accelerated toolchain for WASM that supports unmodified applications compiled to WASM and utilizes diverse Arm hardware features aiming to enrich the memory safety properties of WASM. Precisely, Cage leverages Arm's Memory Tagging Extension (MTE) to (i) provide spatial and temporal memory safety for heap and stack allocations and (ii) improve the performance of WASM's sandboxing mechanism. Cage further employs Arm's Pointer Authentication (PAC) to prevent leaked pointers from being reused by other WASM instances, thus enhancing WASM's security properties. We implement our system based on 64-bit WASM. We provide a WASM compiler and runtime with support for Arm's MTE and PAC. On top of that, Cage's LLVM-based compiler toolchain transforms unmodified applications to provide spatial and temporal memory safety for stack and heap allocations and prevent function pointer reuse. Our evaluation on real hardware shows that Cage incurs minimal runtime (<5.8%) and memory (<3.7%) overheads and can improve the performance of WASM's sandboxing mechanism, achieving a speedup of over 5.1%, while offering efficient memory safety guarantees.

Cage: Hardware-Accelerated Safe WebAssembly

TL;DR

Cage presents a hardware-accelerated toolchain that adds memory safety and improved sandboxing to unmodified -bit WebAssembly programs on ARM, by leveraging MTE and PAC. It introduces a minimal WASM extension with segment-based memory tagging and pointer authentication, integrates an LLVM toolchain and a modified wasi-libc, and implements the safety features in wasmtime. Empirically, Cage achieves low runtime and memory overheads while delivering strong external and internal memory safety guarantees, and it substantially speeds up sandboxing compared to software-only approaches. The work demonstrates that hardware-assisted memory safety for WASM is viable in production settings and offers practical defense-in-depth against memory-safety exploits and cross-instance pointer leakage.

Abstract

WebAssembly (WASM) is an immensely versatile and increasingly popular compilation target. It executes applications written in several languages (e.g., C/C++) with near-native performance in various domains (e.g., mobile, edge, cloud). Despite WASM's sandboxing feature, which isolates applications from other instances and the host platform, WASM does not inherently provide any memory safety guarantees for applications written in low-level, unsafe languages. To this end, we propose Cage, a hardware-accelerated toolchain for WASM that supports unmodified applications compiled to WASM and utilizes diverse Arm hardware features aiming to enrich the memory safety properties of WASM. Precisely, Cage leverages Arm's Memory Tagging Extension (MTE) to (i) provide spatial and temporal memory safety for heap and stack allocations and (ii) improve the performance of WASM's sandboxing mechanism. Cage further employs Arm's Pointer Authentication (PAC) to prevent leaked pointers from being reused by other WASM instances, thus enhancing WASM's security properties. We implement our system based on 64-bit WASM. We provide a WASM compiler and runtime with support for Arm's MTE and PAC. On top of that, Cage's LLVM-based compiler toolchain transforms unmodified applications to provide spatial and temporal memory safety for stack and heap allocations and prevent function pointer reuse. Our evaluation on real hardware shows that Cage incurs minimal runtime (<5.8%) and memory (<3.7%) overheads and can improve the performance of WASM's sandboxing mechanism, achieving a speedup of over 5.1%, while offering efficient memory safety guarantees.
Paper Structure (39 sections, 8 equations, 17 figures, 4 tables, 1 algorithm)

This paper contains 39 sections, 8 equations, 17 figures, 4 tables, 1 algorithm.

Figures (17)

  • Figure 1: WASM's linear memory model.
  • Figure 2: Example of a heap allocation protected by MTE. After allocation, the pointer and allocation are tagged with , while the surrounding memory is tagged with . When accessing memory, the hardware catches out-of-bounds errors ($ \neq $). When freeing memory, the memory region is retagged with . This prevents use-after-free errors ($ \neq $).
  • Figure 3: Pointer layout on aarch64 in Linux with and without MTE and PAC enabled.
  • Figure 4: Performance overhead of MTE sync and async mode for writing 128 MiB of memory. See $\S$\ref{['subsec:experimental-setup']} for details on the experimental setup.
  • Figure 5: Overview of Cage's components and instrumentation pipeline: Unmodified C/C++ code is compiled along with our modified WASI-libc. After optimizations, two sanitizer passes for memory safety and pointer authentication run, inserting new WASM instructions. Wasmtime processes this hardened WASM and emits MTE and PAC.
  • ...and 12 more figures