Hardware security for critical national infrastructure
summary
Claims that hardware-enforced memory safety eliminates the class of spatial and temporal bugs that historically cause about 70% of critical vulnerabilities, demonstrated by Heartbleed’s private-key leak. Uses the CHERI capability model to make pointers distinct from integers and enforce bounds, permissions and provenance, plus a software heap policy and lightweight compartmentalization (demo runs 10–15 compartments in 200–300kB RAM). Core trust is tiny: a boot loader that erases itself and a switcher of ~350 instructions; chips ship next year.
AI-written summary · about
chapters (14)
- 0:00Introduction
- 0:43Memory safety for critical systems
- 3:59Memory safety vulnerabilities
- 6:08Heartbleed case study
- 9:42Memory safety in IoT devices
- 10:24Chariot hardware capability system
- 11:48Long-term embedded support
- 13:35Legal implications of vulnerabilities
- 15:01CVEs in Linux vs Zephyr RTOS
- 15:42Secure systems with memory-safe substrates
- 16:25Privilege separation in Chariot
- 17:49Supply chain risks in libraries
- 19:17Code rights with compartmentalization
- 21:03Fearless code reuse with hardware security
related talks
31mMemory Safety: The Pernicious Challenge
25mLightning Talk: Protecting Zephyr Against Memory Safety Vulnerabilities With the New CHERI Hardware Architecture- 25mLightning Talk: Protecting Zephyr Against Memory Safety Vulnerabilities With the New CHERI Hardware Architecture
32mBuilding in cyber resilience
10mKeynote: Innovation Secured: A Paradigm Shift in the Processor Industry
17mHardening Linux and FreeBSD on RISC-V with CHERI
46mRethinking Architectures and Abstraction for a World Where Security Improvements Matter More than Performance Gains
11mDemo: Securely Booting CHERI on a Full OS to Prevent Buffer Overflow Attacks