Lightning Talk: Protecting Zephyr Against Memory Safety Vulnerabilities With the New CHERI Hardware Architecture
summary
Claims that CHERI gives hardware-enforced bounds and permissions to pointers and can stop exploitation of memory bugs; cites 70% of vulnerabilities and about 100 CVEs in Zephyr tied to memory safety. Work adds a CHERI-aware toolchain, board support, boot and low-level assembly changes, alignment rules, tests, and a prototype development release targeting RISC-V CHERI 0.9.5 (64-bit) that currently runs minimal examples on QEMU but needs more kernel support and upstreaming.
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
18mWhat’s next for memory safety?
10mCHERI in out-of-order microarchitectures
23mHardware security for critical national infrastructure
11mDemo: Securely Booting CHERI on a Full OS to Prevent Buffer Overflow Attacks
01h 33mHands-on Introduction to CHERI