Sealed with a Library Call: Memory Allocators Should Track Capability Seal Opera...
summary
Claim: memory allocators must track capability seal operations or they break when user code seals pointers. Evidence: ports of the Boehm GC and MicroPython to CHERI reveal sealed pointers stop GC traversal (dangling pointers) and cause space leaks with explicit free. Concrete proposals: add a sealed capabilities registration callback or augmented allocator API that records seal/unseal pairs in a lookup table, store weak references for unseals, and prune entries or use kernel-backed revocation; prototype needed.
AI-written summary · about
chapters (7)
- 0:00Introduction
- 0:46Memory allocators need seals
- 3:13Sealed capabilities explained
- 6:28Sealed capabilities in GC
- 8:35Tracking seals in memory
- 10:42Next steps and PoC
- 12:28Q&A
related talks
29mEfficient, Provable Local Capability Revocation using Uninitialized Capabilities
12mLibrary-based Compartmentalisation on CHERI
18mWhat’s next for memory safety?
20mThe Downgrading Semantics of Memory Safety
08mChatGPT, Make a Secure Malloc for me
48mManual Memory Management in .NET Framework
28mMemory simulations, security and optimization in a verified compiler
26mMemory Safety Preservation for WebAssembly