Memory Safety Preservation for WebAssembly
summary
Claims a compiler-based way to preserve memory safety when compiling C to WebAssembly by translating checked pointers into capabilities stored in private module memory and exposing a small, bounds-checked API so untrusted modules cannot tamper with metadata. Presents a short-term, software-only prototype that requires recompiling modules and compartmentalizing mixed safe/unsafe code and reports ongoing performance evaluation and JIT optimizations to reduce check overhead. Proposes a long-term target of MS-Wasm segmented memory and proves preservation using a trace/tag-based memory-safety monitor (work in progress).
AI-written summary · about
chapters (13)
- 0:00Introduction
- 0:25Memory conservatives
- 1:18Our approach
- 2:05Outline
- 2:24Features
- 3:13The Problem
- 5:50Memory Isolation
- 8:40Safe Write
- 9:35Limitations
- 11:51Evaluation
- 12:20MS Rossum
- 14:53Memory Safety Property
- 19:47Future Work
related talks
25mMSWasm: Soundly Enforcing Memory-Safe Execution of Unsafe Code
32mAll The Memory Safety Of C Combined With All The Blazing Speed Of JavaScript
43mRichWasm: Bringing Safe, Fine-Grained, Shared Memory Interoperability to WebAssem...
21mRichWasm: Bringing Safe, Fine-Grained, Shared-Memory Interoperability Down to WebAssembly
34mPlaying Safely in the...
33mKeeping the asm in Wasm – Running high-level languages on a low-level VM
22mThe state of WebAssembly
17mA case for Web Assembly