Revocable: a mechanism for preventing "classic" use-after-free bugs
summary
Proposes revocable as a kernel indirection that decouples resource and consumer lifetimes, adding provider and consumer handles and using RCU/SRCU (calls like synchronize_srcu) so revocation sets the resource pointer to NULL and waits for readers to exit; applies to ChromeOS Embedded Controller drivers where it fixes a real-world use-after-free; offers a fine-grained primitive API and an automated option that swaps file ops (replacing file operations), primitive approach is landed and observed to work.
AI-written summary · about
chapters (17)
- 0:00Introduction to Revocable
- 1:28Classic use-after-free problem
- 3:35Proposed revocable mechanism
- 6:07Implementation details
- 7:32Case study in Chrome OS
- 9:21Solutions comparison
- 10:47Future integration plans
- 11:10Q&A: Subsystem testing
- 12:14Q&A: Kernel vs user space
- 15:28Q&A: TTY layer comparison
- 16:54Q&A: Broader use cases
- 19:23Q&A: Kernel API concerns
- 20:54Q&A: Subsystem volunteer
- 21:36Q&A: User space critical sections
- 24:31Q&A: Driver changes goal
- 25:35Q&A: Consumer-producer patterns
- 26:27Conclusion
related talks
29mEfficient, Provable Local Capability Revocation using Uninitialized Capabilities
54mThe Upcoming Concurrency TS Version 2 for Low-Latency and Lockless Synchronization
01h 01mSmarter Cpp Atomic Smart Pointers - Efficient Concurrent Memory Management
18mWhat’s next for memory safety?
10mKeynote: Innovation Secured: A Paradigm Shift in the Processor Industry
16mMitigating Transient-Execution Attacks with CHERI Compartments
23mTowards Scalable Confidential Computing on RISC-V
29mdrgn Writing to Memory and Breakpoints, Safely in Production?
