Lightning Talk: Protecting Zephyr Against Memory Safety Vulnerabilities With the New CHERI Hardware Architecture
summary
Memory-safety bugs cause about 70% of vulnerabilities and Zephyr records ~100 CVEs with 60–70% memory-safety issues. CHERI enforces bounds and permissions in hardware so pointers become 128-bit capabilities, preventing out-of-bounds access at runtime. Work includes a CHERI-RISC‑V 0.9.5 64-bit prototype in the CHERI Alliance GitHub, a CHERI LLVM toolchain (based on LLVM15), QEMU board support, CHERI GDB, and low-level assembly and boot changes; hello‑world examples run in QEMU but full kernel support and upstreaming remain ongoing.
AI-written summary · about
chapters (19)
- 0:00Memory safety in Zephyr
- 3:34Zephyr needs Cherry architecture
- 6:11Modifications for Cherry support
- 9:46Cherry Zephyr development status
- 10:49Zephyr adopting Cherry now?
- 11:23Q&A: Upstreaming Cherry LLVM
- 12:35Q&A: Hardware solutions comparison
- 13:38Q&A: Pointer assembly boundaries
- 15:03Q&A: Prototype stage and kernel
- 15:48Q&A: Hardware platform availability
- 16:30Q&A: Pointer info in memory
- 17:31Q&A: Testing and hardware exceptions
- 18:14Q&A: Zero-day attack prevention
- 18:57Q&A: Fault handling and firmware
- 19:25Q&A: Cherry for unit tests
- 20:27Q&A: Runtime capability checking
- 21:18Q&A: Compiler intrinsics and capability
- 22:21Q&A: Pointers to IO memory
- 24:29Summary and future directions
related talks
25mLightning Talk: Protecting Zephyr Against Memory Safety Vulnerabilities With the New CHERI Hardware Architecture
31mMemory Safety: The Pernicious Challenge
17mHardening Linux and FreeBSD on RISC-V with CHERI
10mCHERI in out-of-order microarchitectures
18mWhat’s next for memory safety?
23mHardware security for critical national infrastructure
11mDemo: Securely Booting CHERI on a Full OS to Prevent Buffer Overflow Attacks
53mLinux and CHERI: Back to the Future