Adventures in Making Wasm Fast and More Secure
summary
A practicality-first toolchain moves real C/C++ libraries into WebAssembly sandboxes using RLBox to auto-insert taint types and require sanitizers, and wasm2c + clang/GCC to round-trip SIMD code; Firefox ships multiple sandboxed libraries across Linux, macOS, Windows and Android with typical overheads cut from ~30–40% to ~7% (XML parsing 7%, font decompression ~10%). An automated sanitizer checker finds missed checks, a segmentation-based backend segue removes up to ~75% of Wasm overhead and shrinks binaries ~6%, and a small CPU extension design (HFI) targets near-zero isolation cost.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 1:44Why WebAssembly for security
- 3:54In-process sandboxing challenges
- 7:48Introducing RLbox
- 10:36RLbox in Firefox production
- 14:52Performance improvements
- 18:47Security benefits of RLbox
- 21:1632-bit CPU challenges
- 24:05Automating sanitizer checks
- 25:53Verifying WebAssembly security
- 29:01Speculative execution safety
- 32:15Hardware acceleration for isolation
- 35:48CPU extensions for WebAssembly
- 38:38Future of Wasm adoption
related talks
30mDon't Get Owned by Dependencies: How Firefox Uses Wasm to Protect Itself from Exploitable Libraries
32mDon't Get Owned by Your Dependencies
48mDon't Trust Anything! Real-world Uses For WebAssembly
53mWebAssembly
50mWeb Assembly
36mSafety-Critical Meets Web-Native: Wasm Revolutionizes Embedded Systems
30mShrinking Software Attack Surface with WebAssembly & CNCF Wasmcloud
21mHit the Ground Running with WebAssembly