Two Paths to Memory Safety: CHERI and OMA

Summary

The last year has been brutal for businesses globally. Taking examples from my home country, the UK, the cost is over £1B and still rising, as well as the loss of at least one life due to cybercrime. These aren’t isolated incidents - they’re symptoms of a systemic vulnerability in how we build computer systems. According to the Verizon 2025 Data Breach Investigations Report, credential abuse and exploitation of vulnerabilities continue to dominate as attack vectors, accounting for 22% and 20% of breaches respectively. The exploitation of vulnerabilities saw a 34% surge year-over-year, creating what Verizon describes as a “concerning threat landscape”. We’re yet to learn the root causes and attack chains involved in each of the examples above, but many involved ransomware, which frequently uses software exploits as a post-initial-access vector to gain control of target systems and spread across a network. Here’s the kicker: approximately 70% of all software vulnerabilities stem from a single root cause - memory safety issues. This isn’t a new problem. Google, Microsoft, Apple, Mozilla and the Linux Foundation have all reported similar figures for their software over the last two decades. The uncomfortable truth is that current CPUs are fundamentally incapable of preventing these vulnerabilities, and traditional software patches have proven woefully inadequate. Rewriting all the world’s software into memory safe languages, such as C#, Java and Rust, is unviable. While new projects may be adopting Rust over C/C++, and some critical components are being rewritten into safe languages, the scale and depth of the C and C++ ecosystems makes it practically impossible to rewrite all the world’s unsafe software. The risk of introducing other (non-memory-safety) issues during a software rewrite also poses a substantial barrier. Given sufficient software compatibility, it is actually easier to swap the hardware! Two architectural approaches have emerged to tackle this trillion-d...