Performant Bounds Checking for 64-Bit WebAssembly
summary
Implements and compares four approaches inside a C++ Wasm runtime (LLVM-based codegen, Linux mprotect + signal-to-exception trampoline): plain software checks, masked 64-bit guard pages, two-level guard pages that map 1 GB chunks to micro-guard pages, and experiments with x86-64 memory keys. Benchmarks (four SPEC CPU ports + a custom microbenchmark, single-threaded) show software checks can exceed 100% overhead while the two-level scheme drops overhead to 12.7%, and the paper reports an optimal macro/micro region at 256 GB each (512 GB total).
AI-written summary · about
chapters (14)
- 0:00WebAssembly intro
- 1:02Why WebAssembly outperforms JavaScript
- 2:05Bounds checking basics
- 4:15Software bounds flaws
- 6:4532-bit guard pages
- 8:32CPU exceptions to WASM traps
- 10:3764-bit address challenges
- 12:2264-bit guard pages
- 14:08Two-level guard pages
- 17:23Optimizing guard page sizes
- 18:28Benchmarking bounds checks
- 20:3665-bit overflow handling
- 22:44Summary and future
- 23:04Q&A: Memory allocation
related talks
37mBridging the Architecture Divide: How Hardware Limits Wasm, and How We Can Do Better
26mMemory Safety Preservation for WebAssembly
26mSyscall Me by Your Name: Sandboxing Wasm Programs
42mAdventures in Making Wasm Fast and More Secure
24mWebAssembly as an Intermediate Language for Provably-Safe Software Sandboxing
39mBeyond the Baseline: Experimental WebAssembly for High Performance
25mMSWasm: Soundly Enforcing Memory-Safe Execution of Unsafe Code
18mIndexed Types for a Statically Safe WebAssembly