Memory Safety: The Pernicious Challenge
summary
Panel claims CHERI can block over 70% of memory vulnerabilities and demonstrates concrete progress: a full port of OpenWrt to pure‑cap CHERI takes a few months and removes the tested memory bugs, but widespread deployment stalls because CHERI hardware availability is limited. Industry work is underway — Kodasip is contributing QEMU and LLVM support and a CHERI Alliance forms to coordinate IP, tooling, CI/CD and vendor interoperability so software can run across silicon.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 2:39Innovate UK’s goals
- 6:11Industry’s role in Cherry
- 9:25Adopting Cherry in IoT
- 11:33Why memory safety took decades
- 13:40Prioritizing silicon vendors
- 17:52Government’s secure-by-design role
- 21:02Securing legacy IoT devices
- 23:52Memory safety and identity together
- 25:38Building Cherry ecosystem
- 28:51Cherry long-term vision
- 31:01Closing remarks
related talks
18mWhat’s next for memory safety?
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
20mMaking CHERI Accessible
17mHardening Linux and FreeBSD on RISC-V with CHERI
53mLinux and CHERI: Back to the Future
23mHardware security for critical national infrastructure
10mCHERI in out-of-order microarchitectures
