For anyone who missed CHERITech, there’s an online after party on the 4th! The talks will be online shortly and then CHERITech Reloaded will give you an opportunity to ask questions.
So you have two weeks to think of awkward questions for me about CHERIoT Audit! Good luck!
For folks who missed my #KISV keynote or #CHERITech talk, I wanted to pull out the two key points.
The first is that CHERI solves memory safety, but that’s almost incidental. I don’t want to downplay addressing the root cause of 70% of vulnerabilities but that’s not the goal. CHERI was originally designed to support scalable fine-grained compartmentalisation. To do that well, you need a programmer model. You need to be able to share things programmers understand (objects, in object graphs) not pages. And that means you need to be able to trivially map your protection up to language-level constructs like pointers / references and protect both them and the objects that they refer to. And so you need to build memory safety. And, it turns out, making an entire program memory safe is much easier than making just an exposed API memory safe. So we have memory-safe C/C++ and we can use those from languages like Java or Rust to ensure that the C/C++ doesn’t violate the guarantees that the safe language’s security depends on. And then we can use that for easy to use compartmentalisation, safe FFI, supply-chain security, and many more things.
The second is that CHERI is still quite young. I gave a talk about how CHERI impacted OS design. That’s like, in 1985, asking someone from IBM to give a talk about how MMUs impacted OS design. They would tell you you could create VMs to consolidate multiple minicomputers onto a single mainframe. They would tell you that you could enforce process isolation. And, just like the things we can do with CHERI today, these are hugely valuable. But they wouldn’t tell you about using Zygote models to speed up process creation. They wouldn’t tell you about how memory-mapped files could enable new I/O models. They wouldn’t tell you about how IOMMUs could enable kernel-bypass storage and networking. They wouldn’t tell you about how MMUs can introduce lightweight GC barriers. They wouldn’t tell you about how MMUs enable lightweight CoW snapshots for time-trace debugging. Because, although a lot of the hardware existed for these things (and the rest was a fairly small incremental tweak on existing ideas), most of these software uses hadn’t been invented.
CHERI is exactly the same. We have barely scratched the surface of what CHERI can let you build. The BLACKOUT work (presented at CCS and again at CHERITech) is another great example of this. I had never thought of using CHERI as a building block for providing a clean programmer model for avoiding side channels, but some other smart people did and proposed a really interesting model for doing so. I hope future CHERI systems will incorporate something based on this work.
As with MMUs in the early ‘80s, we have no idea what people will be building on top of CHERI in ten or twenty years. Many of these things will be possible on existing implementations, some will require hardware changes. This is why it’s very important for the RISC-V CHERI standard to be designed with agility in mind, so that future hardware can continue to add new and exciting features without breaking backwards compatibility for software. I think we’re on a good path to that.
Yay, the embargo was finally lifted yesterday so we can talk about the UK Government funding for #CHERIoT!
They funded us (SCI) to do two projects, for a total of £7.7M:
Sealing is one of the oldest parts of CHERI and one of the most powerful. When I joined the project in 2012 it was integral to the early prototype call-gate mechanism. You can find this version in our 2014 tech report. It included CSealCode and CSealData instructions that assembled a pair of capabilities that could be used with the CCall instruction to perform a cross-compartment call. By our IEEE Security and Privacy 2015 paper, this had been replaced with the modern sealing mechanism that we use today.
“Fil-C: A Memory-Safe C Implementation”, LWN (https://lwn.net/SubscriberLink/1042938/658ade3768dd4758/).
On HN: https://news.ycombinator.com/item?id=45735877
On Lobsters: https://lobste.rs/s/mg0aur/fil_c_memory_safe_c_implementation
Great to see so many OS folks at SOSP last week when we presented the CHERIoT RTOS paper (and not to be the only one presenting work on CHERI)!
The paper is now live in the ACM Digital Library and already has almost 2,000 downloads. Hopefully a few of those will even translate to people reading it!
I'm joining @cheri_alliance@cheri_alliance@infosec.exchange as an ambassador, working to transform cybersecurity at its foundation.
Memory safety bugs cause 70% of cyber vulnerabilities, leading to disasters like OpenSSL Heartbleed and the 2024 CrowdStrike outage ($5.4 billion in losses). CHERI technology, developed over 15 years by Cambridge University and SRI International, prevents these attacks through hardware-enforced memory protection rather than endless software patches.
The momentum is extraordinary. The UK government invested £80 million alongside £200 million from industry, with backing from DSIT, NCSC/GCHQ, DSTL, and DARPA. Industry giants Google, Microsoft, and Arm have joined alongside BT Group and Siemens, recognizing that hardware-level security is no longer optional.
I'm particularly excited about our working groups porting critical operating systems to CHERI. FreeBSD, FreeRTOS, Zephyr, and seL4 have all been ported to run on CHERI hardware, with teams actively developing and maintaining these implementations. This ecosystem work ensures CHERI can protect everything from embedded IoT devices to enterprise servers, making memory safety accessible across the entire computing stack.
Microsoft found CHERI would have prevented two-thirds of their 2019 vulnerabilities. The technology is practical too – existing software often needs less than 0.03% code changes to become memory-safe. As we deploy AI and connect critical infrastructure, we can't afford to keep patching symptoms. CHERI addresses the root cause.
Join us in building secure-by-design systems. The Alliance welcomes all who share this vision. Let's stop playing defense and fundamentally solve memory safety.
Two architectural approaches have emerged to tackle the trillion-dollar memory safety problem at the hardware level: CHERI (Capability Hardware Enhanced RISC Instructions) and OMA (Object Memory Architecture). Both aim to make memory-unsafe code safe by design, but they take fundamentally different paths to get there. This article looks at the design differences and their impact on commercial applications.
David Chisnall (*Now with 50% more sarcasm!*)
Michael Engel
रञ्जित (Ranjit Mathew)
Raurquiz
Minsoo Choo 
GripNews