CHERI memory safety demonstrates how hardware architecture can enhance pointer safety without extensive code rewriting. For architects and SREs, this is an important example of how the boundary between hardware, software stack, and model of trust is changing.
As a system grows, the main issue often is no longer isolation per se. Processes, VMs, and MMUs have long been capable of separating workloads. Complexity arises when two parts of the system need not only to be separate but also to exchange data securely. It is at this moment that architecture confronts the question: what does the sharing model look like, rather than just the isolation model? In CHERI, this question is placed at the center.
The choice of CHERI appears pragmatic. Instead of addressing security solely at the OS level or rewriting applications, the approach shifts some guarantees into hardware. A hardware-enforced pointer type emerges, where a pointer is not just a number but a capability with bounds, permissions, and a tag bit. This provides spatial and temporal memory safety for C/C++, but with an important trade-off: the system becomes stricter regarding memory handling, yet maintains compatibility with existing code. It is also worth noting that CHERI is not a single fixed ISA. It is a set of ideas that can be localized to different architectures, including AArch64 Morello and CHERIoT for microcontrollers.
In implementation, the mechanics are crucial, not slogans. A CHERI capability stores an address and metadata, including bounds and permissions. These boundaries do not expand back: they are monotonic. If a pointer is narrowed to a field or sub-object, the original context can only be restored through re-derivation from another trusted pointer. This is good for security but imposes discipline on the codebase and memory model. There is also a nuance with storage: a capability carries a tag bit that indicates that the value is indeed a pointer. When memory is partially overwritten, the tag is cleared, and the system no longer interprets the data as a capability. This is an important detail for operations like memcpy, where copying must be type-oblivious.
Another layer of architecture is compartmentalization. CHERI allows for the replacement of costly OS-level RPC mechanisms with lighter and auditable inter-component boundaries. This is not a free improvement. However, it reduces communication overhead between parts of the system compared to heavier isolation schemes. This is especially noticeable for embedded scenarios. CHERIoT demonstrates that the approach scales down to microcontrollers while maintaining source compatibility. For teams that have lived with C code for decades, this is significant: there is no need for extensive rewriting to achieve a new level of memory control.
From an engineering perspective, CHERI is also interesting because it changes the very cost of trust. Previously, security often depended on agreements in code and team discipline; here, part of the invariants moves into silicon. This does not eliminate errors but narrows the class of errors that can lead to isolation violations. At the same time, the system does not become magical. It requires an understanding of how pointer capabilities propagate, where they narrow, and how they behave during copying or loading from memory.
For architects, there is an important takeaway. Memory safety and trust boundaries are better designed as part of platform architecture rather than as a set of local patches. CHERI offers precisely this shift. It is an evolutionary improvement, not a cosmetic overlay: it changes the interaction model between hardware, software, and trust boundaries. And that is why it should be viewed not as yet another security initiative but as an architectural tool for systems where isolation and sharing must coexist without fragile compromises.