CHERI and Capability Hardware: Memory Safety at the Gate Level

If you have written C or C++ for more than about a week, you have written a memory safety bug. If you have written C or C++ for a career, you have written thousands of them. Some you caught. Some the compiler caught. Some became CVEs with nine-point severity scores and their own Wikipedia pages. The uncomfortable truth of systems programming is that the programming model — a flat array of bytes indexed by raw pointers — is fundamentally unsafe, and fifty years of static analysis, sanitizers, fuzzers, and safer languages have not changed the fact that most of the world’s critical software infrastructure is written in C and C++ and will remain so for decades.

CHERI — Capability Hardware Enhanced RISC Instructions — is an attempt to fix this at the hardware level. Not by eliminating C and C++, not by adding a software abstraction layer, but by changing what a pointer is. In a CHERI system, a pointer is not a 64-bit integer that happens to be interpreted as an address. It is a 128-bit (or compressed 64-bit) capability: an unforgeable token that encodes a base address, a bound, a set of permissions, and an object type. The hardware enforces that every memory access through a capability falls within its bounds and respects its permissions. You cannot forge a capability from raw bits. You cannot widen a capability’s bounds. You cannot add permissions you were not granted. The result, if implemented correctly, is that entire classes of vulnerabilities — buffer overflows, heap corruption, return-oriented programming — become architecturally impossible, not just practically difficult.

This is not a hypothetical research project. CHERI has been implemented in silicon on the Arm Morello prototype, a CHERI-extended ARMv8-A processor taped out in 2021 and shipped to researchers in 2022. It is being standardized as the Zcheri extension for RISC-V. And it represents, in my view, the most important architectural innovation in processor security since the introduction of protected mode in the 80286 — except that CHERI actually works at scale, with existing codebases, with tolerable overhead.

This post is a deep dive into CHERI: the capability format and CHERI Concentrate compression, the temporal safety story (the load barrier and sweeping revocation), the Arm Morello implementation and what we learned from it, the formal verification challenges that keep capability integrity honest, and the open questions that remain as CHERI moves from research prototype to production silicon.

1. Why Flat Address Spaces Are Broken

Before we dive into capabilities, let us be precise about what is wrong with the status quo. In a conventional architecture — x86, ARM, RISC-V without CHERI — memory is a flat array of bytes addressed by 64-bit (or 32-bit) virtual addresses. The OS sets up page tables that control which virtual addresses a process can access and with what permissions (read, write, execute). So far, so good: virtual memory provides inter-process isolation.

The problem is intra-process isolation. Within a process’s virtual address space, every pointer can access every address that the page tables permit. There is no architectural distinction between a legitimate pointer to a heap-allocated buffer and an attacker-controlled pointer that happens to point to the same process’s stack, or to its global offset table, or to a function pointer that will later be called. If an attacker can overwrite a function pointer — through a buffer overflow, a use-after-free, or a format string bug — they can redirect control flow to an address of their choosing.

Mitigations exist, but they are all reactive and partial. Stack canaries detect linear buffer overflows but not arbitrary writes. ASLR (Address Space Layout Randomization) makes it harder to predict addresses but can be defeated by information leaks. Control-flow integrity (CFI) restricts indirect branches to a set of valid targets but can be bypassed with techniques like COOP (Counterfeit Object-Oriented Programming). Memory tagging (MTE on ARM, coming to x86) probabilistically detects use-after-free but allows a certain fraction of attacks through. All of these are probabilistic defenses in an adversarial game where the attacker only needs to win once.

CHERI changes the game from probabilistic to deterministic — at least for spatial memory safety. A CHERI capability defines the exact bounds of the object it references. Any access outside those bounds traps. No amount of attacker cleverness can turn a pointer to a 64-byte buffer into a pointer to the adjacent function pointer, because the hardware will not allow it. The bounds are not a software convention that can be violated; they are enforced by the load/store unit on every memory access.

2. The CHERI Capability Format and CHERI Concentrate

A CHERI capability is, architecturally, a 128-bit value. The naive encoding would be straightforward: 64 bits for the base address, 64 bits for the bound (or length), plus some permission bits. That would require more than 128 bits — you also need to represent the current address (the pointer itself), plus permissions, plus an object type. And 128-bit pointers would roughly double the memory footprint of pointer-heavy data structures, which is unacceptable for practical adoption.

CHERI Concentrate is the answer. Developed by Robert N. M. Watson and colleagues at the University of Cambridge, CHERI Concentrate is a compression scheme that fits a full architectural capability — base, bound, address, permissions, and object type — into 128 bits (or, in the compressed 64-bit variant, into 64 bits at the cost of some precision). The key insight is that bounds do not need full 64-bit precision. Most objects are small, and their bounds can be represented with fewer bits. A 32-byte buffer does not need a 64-bit length field; 5 bits would suffice. CHERI Concentrate exploits this by using a floating-point-like representation for bounds, where the precision varies with the magnitude.

Here is the full 128-bit format:

    127 ... 115  114 ... 109  108 ... 90  89 ... 64  63 ... 0
    +-----------+-----------+-----------+----------+---------+
    |  perms    |  otype    |  Bounds   |  Base    | Address |
    +-----------+-----------+-----------+----------+---------+
      13 bits     6 bits      19 bits     26 bits    64 bits

Wait — that does not add up to 128 bits. Let me be more precise. The actual encoding is more subtle because the bounds and base share encoding space. The CHERI Concentrate encoding uses a variable-length exponent for the bounds, similar to how IEEE 754 floating-point represents numbers. The key parameters are:

• Address (64 bits): The current pointer value. Must be within [base, base + bound).
• Base (variable): The lower bound of the capability. Encoded relative to the address using a compressed representation.
• Bounds (variable): The length of the accessible region. Encoded as an exponent and a mantissa.
• Permissions (up to 26 bits in the full format): Bits for load, store, execute, capability load/store (access to capability registers), and various system permissions.
• Object type (up to 24 bits in the full format): Used for sealed capabilities — capabilities that cannot be dereferenced but can be used as opaque tokens for delegation.

The compression works as follows. For a capability with base B, length L, and address A (where B ≤ A < B + L), the encoding stores A directly (64 bits). The bound L is decomposed into an exponent E and a mantissa M, where L ≈ M × 2^E. The base B is stored as a correction relative to A, using the same exponent. The result is that a capability fits in 128 bits regardless of the actual size of the object, at the cost of some precision loss in the bound representation. For a 32-byte buffer, the bound is exact. For a 2 GB buffer, the bound might be rounded up to the nearest 256 MB — still providing safety (you can access slightly more than intended, but not arbitrarily more), but not byte-exact.

The compressed 64-bit format — used when capabilities are stored in memory in pointer-heavy data structures — is even more aggressive. It stores only the address (64 bits) and relies on a separate “capability table” in memory to hold the full 128-bit metadata. A load of a compressed capability fetches the address and then looks up the metadata from a designated table entry, indexed by a hash of the address. This allows C code that expects 64-bit pointers to work with CHERI without changing data structure layouts — the compiler emits capability-aware load/store instructions that handle the decompression/compression transparently. The cost is an extra memory access for each capability load, but this is often hidden by caching: the capability table is small and highly associative.

3. Temporal Memory Safety: The Load Barrier and Sweeping Revocation

CHERI provides deterministic spatial memory safety: a capability’s bounds prevent out-of-bounds access. But temporal memory safety — ensuring that a capability is not used after the underlying object has been freed — is harder. When free(p) is called, the capability p still exists in registers and in memory. It still points to the (now freed) memory region, and its bounds still describe that region. Nothing in the CHERI architecture automatically invalidates it.

The CHERI approach to temporal safety is called the load barrier. It works in concert with a modified memory allocator that uses a technique called sweeping revocation. Here is how it works:

1. The allocator maintains a quarantine list: a set of recently freed objects whose capabilities might still be reachable.
2. Periodically (or when memory pressure demands it), the allocator initiates a revocation sweep. It scans all of memory — registers, stack, heap — looking for capabilities that point into quarantined objects.
3. Capabilities found to point into quarantined objects are either zeroed (invalidated) or modified to point to a special “revoked” sentinel.
4. Once a quarantined object has no remaining capabilities pointing to it, it is safe to reuse the memory.

The “load barrier” is the hardware mechanism that makes this efficient. On a CHERI processor, a special instruction — call it ldbr or a variant of the load instruction with a barrier bit — loads a capability and simultaneously checks it against a “barrier epoch” value stored in a special register. If the capability was created before the current barrier epoch, it is treated as invalid. This allows the allocator to revoke capabilities lazily: it increments the barrier epoch, which invalidates all outstanding capabilities, without having to scan memory for each individual free. The scanning still happens, but it happens asynchronously and in batches.

The performance of sweeping revocation depends on the rate of allocation and the size of the scanned memory. In the Arm Morello prototype, the overhead for temporal safety (load barrier + sweeping revocation) was measured at roughly 5-15% for allocation-intensive benchmarks, with most of the cost being the memory scanning rather than the barrier checks. This is not free, but it is far cheaper than alternative approaches like garbage collection (which requires the allocator to track all live pointers with exact precision) or memory tagging (which is probabilistic and allows a fraction of use-after-free errors to escape detection).

An important nuance: the CHERI load barrier does not prevent all temporal safety violations. It prevents the use of a dangling capability to access freed memory, but it does not prevent the corruption that can occur if a freed object is reallocated for a different purpose and the old capability — if not yet revoked — is used to access the new object. This is a type confusion attack: the attacker tricks the program into treating an object of type A as though it were type B. CHERI’s object type field can help here — if the allocator sets the object type when allocating and checks it on dereference — but this requires the allocator and the compiler to cooperate, and it is not yet part of the standard CHERI specification.

4. The Arm Morello Prototype: What We Learned

Arm Morello is the most significant CHERI implementation to date. It is a complete system-on-chip built around a CHERI-extended ARMv8-A processor — essentially, a modified Cortex-A class core with full 128-bit capability registers, a capability-aware memory system, and all the software infrastructure needed to run a real operating system. Morello boards were shipped to researchers in 2022 through the UK’s Digital Security by Design (DSbD) program, and the results have been illuminating.

The Morello processor implements what is called “pure-capability” mode: a mode in which all pointers are 128-bit capabilities, not just selected ones. This is the most aggressive CHERI configuration, and it provides the strongest security guarantees because there are no “plain” pointers that can bypass the capability checks. In pure-capability mode, the C compiler (a modified version of Clang/LLVM) treats every pointer as a capability. The kernel (a modified version of FreeBSD, called CheriBSD) manages capability creation and revocation. User-space applications — including a full KDE desktop — run with full spatial memory safety.

The headline result from Morello is that it works. A full desktop environment, running unmodified KDE applications compiled for CHERI, provides deterministic protection against buffer overflows. The performance overhead is in the 10-15% range for most workloads, with some outliers (pointer-heavy code, like the Boehm garbage collector, sees higher overhead). This is not negligible — a 10% performance regression would be unacceptable for some applications — but it is far lower than the overhead of software-only memory safety approaches like AddressSanitizer (2× slowdown) or Valgrind (10-20× slowdown).

More interesting than the headline numbers are the subtle lessons. One is that porting C code to CHERI is not always straightforward. C code that relies on pointer arithmetic that crosses allocation boundaries — for example, computing a pointer to the byte just past the end of an array and then subtracting to get the length — breaks under CHERI because the out-of-bounds pointer traps. The C standard explicitly allows a pointer to point “one past the end” of an array (for use in loop termination conditions), and CHERI must support this — which it does, by allowing capabilities to be incremented up to one element beyond the upper bound, but dereferencing that pointer still traps.

Another lesson concerns the performance impact of 128-bit pointers. Doubling the size of every pointer increases cache pressure and memory bandwidth consumption, which hurts performance even when the capability checks themselves are fast. The Morello team found that the compressed 64-bit capability format — where capabilities in memory are stored as 64-bit values with out-of-band metadata — largely mitigates this, but at the cost of extra complexity in the memory system. The long-term solution is probably a hybrid: 128-bit capabilities in registers for precise bounds, 64-bit compressed capabilities in memory for density, with the hardware handling the conversion transparently.

A third lesson is about the software ecosystem. CHERI requires changes to the entire stack: the compiler (to emit capability-aware instructions), the linker (to handle capability relocations), the dynamic linker (to resolve capability-based symbols), the kernel (to manage capability creation and revocation), and the C library (to implement malloc/free with the load barrier). This is a significant engineering effort, and the Morello project succeeded because it had the resources (a multi-year, multi-million-pound government program) to make all of these changes. For CHERI to be adopted commercially, this effort needs to be replicated across multiple architectures and operating systems — a challenge that the CHERI Alliance (an industry consortium formed in 2023) is working to address.

5. Formal Verification of Capability Integrity

If you are going to bet your security on hardware-enforced capabilities, you had better be damn sure the hardware gets it right. A bug in the capability enforcement logic — a microarchitectural race condition that allows a capability to be dereferenced without bounds checking, or a speculative execution path that leaks capability metadata — would undermine the entire security model. This is where formal verification enters the picture.

The CHERI team has been applying formal methods to the capability specification since the project’s inception. The key artifacts are:

1. The CHERI ISA specification in Sail. Sail is a domain-specific language for specifying instruction set architectures, developed at the University of Cambridge and used by ARM for its official ARMv8-A specification. The CHERI Sail specification provides a precise, executable definition of every CHERI instruction — what it does to the architectural state, which capability checks it performs, and what exceptions it can raise. The Sail specification is the golden reference: if an implementation disagrees with it, the implementation is wrong.

2. The capability integrity theorem. The core security property that CHERI must satisfy is that capabilities cannot be forged. Formally: if a capability C grants access to a memory region [B, B+L) with permissions P, then there is no sequence of instructions, starting from any architecturally reachable state, that can construct a capability C’ that (a) grants access to an address outside [B, B+L) or (b) grants permissions not in P, without C’ being derived from an existing capability that already granted those accesses. This theorem has been formalized in Isabelle/HOL (a proof assistant) and proven for the CHERI instruction set.

3. Microarchitectural verification. The ISA-level theorem only guarantees that the architecture is secure if the implementation follows the specification. Microarchitectural features like caches, speculative execution, and out-of-order execution can create side channels that leak capability information or timing differences that reveal bounds. The CHERI team has developed a methodology for verifying microarchitectural designs against the ISA specification using the Kami processor verification framework (from MIT), which allows the designer to write the microarchitecture in a hardware description language embedded in Coq (a proof assistant) and prove refinement against the ISA specification.

The practical impact of formal verification on CHERI has been significant. During the development of the Morello processor, the formal specification caught several bugs that had escaped conventional testing — including a subtle interaction between capability bounds checking and the ARM内存 ordering model that could have allowed a bounds check to be reordered after a memory access on a weakly consistent memory system. These are exactly the kinds of bugs that would be nearly impossible to find through testing and devastating if they reached production silicon.

The challenge going forward is scaling formal verification to production processor designs. The full Arm Morello processor is too complex to verify end-to-end with current formal methods. The verification effort focused on the capability enforcement logic — the load/store unit, the capability register file, and the instruction fetch/decode path — while relying on conventional verification (testing, simulation, emulation) for the rest of the design. This is a pragmatic compromise, but it leaves open the possibility of bugs in the unverified parts of the design that could compromise capability integrity through subtle interactions. The long-term goal, articulated in the CHERI research roadmap, is to develop modular verification techniques that allow each component of the processor to be verified independently, with a compositional proof that the composition preserves the security property.

6. CHERI-RISC-V: The Standardization Effort

While Morello is an ARM-based implementation, the long-term home of CHERI is likely to be RISC-V. The RISC-V International CHERI Task Group, formed in 2022, is working to standardize CHERI as the Zcheri extension to the RISC-V ISA. The draft specification is public and under active development.

The Zcheri extension defines:

• A set of 32 capability registers (c0-c31), which shadow the integer registers and hold 128-bit capabilities.
• Capability-aware variants of load, store, jump, and branch instructions.
• Instructions for capability manipulation: cgetaddr (extract address), cgetbase (extract base), cgetbounds (extract bound), csetbounds (set bound, narrowing), csetaddr (set address, within existing bounds), candperm (mask permissions, attenuating), cseal (seal a capability as an opaque token), cunseal (unseal if the object type matches).
• Control-flow capabilities: sealed capabilities used as jump targets to implement forward-edge control-flow integrity. A cjALR (capability jump and link register) instruction checks that the target capability is sealed with the expected object type, providing a hardware-enforced return address protection similar to ARM’s PAC (Pointer Authentication).

One notable design choice in Zcheri is the handling of the null capability. In standard RISC-V, register x0 is hardwired to zero. In CHERI-RISC-V, the corresponding capability register c0 is the null capability — a capability that grants no permissions and traps on any dereference. This elegantly extends the RISC-V convention: just as arithmetic on x0 produces zero, loads through c0 trap. It also provides a natural representation for the C NULL pointer: a capability with zero address and zero bounds.

The Zcheri standardization process is expected to take several years, with ratification targeted for 2025-2026. In the meantime, experimental CHERI-RISC-V implementations exist in FPGA form (from the Cambridge CHERI team and from lowRISC), and the Sail specification has been updated to cover the RISC-V variant. The open nature of RISC-V makes it a particularly good fit for CHERI: unlike ARM, where adding CHERI required negotiating with ARM’s architecture team and modifying a proprietary ISA, RISC-V’s extension framework allows CHERI to be added as a standard extension that any implementer can choose to include.

7. CHERI vs. The Competition

CHERI is not the only approach to hardware-enforced memory safety. It is worth comparing it with the alternatives to understand where it fits.

Memory Tagging (MTE / MTE2). ARM’s Memory Tagging Extension (MTE) assigns a 4-bit “tag” to each 16-byte granule of memory and maintains a corresponding tag in the upper bits of each pointer. A load or store checks that the pointer tag matches the memory tag; a mismatch indicates a probable use-after-free or buffer overflow. MTE is probabilistic: with 4-bit tags, there is a 1/16 chance that a random pointer matches the tag, so the attacker has a 6.25% chance of success per attempt. MTE2 (announced for ARMv9) extends the tags to 8 bits, reducing the probability to 1/256 ≈ 0.4%. MTE is much cheaper than CHERI in hardware — it adds only a few percent to the area of a processor core — and it is transparent to software (the compiler does not need to change pointer representations). The tradeoff is that MTE is probabilistic while CHERI is deterministic: CHERI guarantees that out-of-bounds access traps, MTE only guarantees that it probably traps.

Intel MPX (deprecated). Intel’s Memory Protection Extensions, introduced in Skylake and deprecated in 2019, provided bounds-checking instructions that software could use to implement pointer-bounds pairs. MPX was unpopular because it was slow (the bounds checks were performed by software, not hardware) and it required significant compiler and runtime support. CHERI learned from MPX’s failure: put the checks in hardware, not software, and make them fast enough to be always-on.

Software-only approaches. AddressSanitizer (ASan) and MemorySanitizer (MSan) use compiler instrumentation to detect memory errors. ASan adds a red zone around each allocation and checks on each memory access whether the address falls within a valid allocation. The overhead is 2× in CPU and 2-3× in memory. SoftBound and CETS (from the University of Pennsylvania) implement software-only fat pointers — essentially, CHERI in software — with overheads of 50-100%. These approaches are valuable for debugging and testing, but their overhead is too high for production deployment.

Safe languages (Rust, Go, Java). The most effective way to prevent memory safety bugs is to use a language that makes them impossible by construction. Rust’s ownership system prevents use-after-free and data races at compile time. Go and Java use garbage collection to prevent use-after-free. The problem is that the world runs on C and C++, and rewriting billions of lines of critical infrastructure code in Rust is a multi-decade project. CHERI provides memory safety for existing C/C++ code without requiring a rewrite. This is its killer value proposition: deploy CHERI hardware, recompile your C code, and you get deterministic spatial memory safety essentially for free (plus temporal safety with some allocator changes).

8. CHERI in Practice: Use Cases and Deployment

Where is CHERI likely to be deployed first? The answer follows the usual technology adoption curve: start with the highest-value, lowest-elasticity applications and expand from there.

High-assurance systems. Military, aerospace, and critical infrastructure systems have stringent security requirements and are willing to pay a premium for hardware-enforced isolation. The UK government’s DSbD program, which funded Morello, is explicitly targeting these markets. If CHERI can prevent remote code execution in a fighter jet’s flight control computer or a nuclear power plant’s SCADA system, the performance overhead is a rounding error compared to the cost of a compromise.

Automotive. Modern cars contain over 100 million lines of code running on dozens of electronic control units (ECUs). The trend toward autonomous driving increases the attack surface (more network connectivity, more sensors) and the consequences of a compromise (a hacked car can kill people). Automotive safety standards (ISO 26262) are beginning to require freedom from memory safety errors at the highest integrity levels (ASIL D). CHERI provides a path to satisfying these requirements without rewriting the entire automotive software stack.

Cloud computing. Cloud providers run untrusted customer code on shared infrastructure. Today, the isolation boundary is the virtual machine — an entire guest OS in its own address space, with all the overhead that entails. CHERI enables fine-grained compartmentalization within a single address space: a customer’s image processing library can be given capabilities that grant access only to the input and output buffers, not to the rest of the server’s memory. If the library has a buffer overflow vulnerability, it cannot be exploited to access other customer data. This is the promise of CHERI-based software compartmentalization, demonstrated in research systems like SOAAP (Software On Arm’s Architecture Protections) and CheriBSD’s c18n compartmentalization framework.

Consumer devices. The final frontier. Apple, Google, and Microsoft are all investing in memory safety — Apple with MTE on the A14 and later chips, Google with MTE on Tensor, Microsoft with the Windows memory integrity features. CHERI provides stronger guarantees than MTE, but at higher cost. Whether the cost premium (in silicon area, power, and performance) is justified for consumer devices depends on how much consumers value security — which, historically, has been “not very much” until a highly publicized vulnerability changes the calculus. If CHERI can prevent the next Stagefright (Android) or Pegasus (iOS) exploit, the value proposition becomes compelling.

9. Open Problems and Research Directions

CHERI is a mature research project transitioning to commercial adoption, but significant open problems remain.

Temporal safety without scanning. The load barrier and sweeping revocation provide temporal safety, but the memory scanning overhead is a concern for large-memory systems (imagine scanning 1 TB of RAM for dangling capabilities). Research on non-scanning revocation — using epoch-based reclamation, hazard pointers, or reference counting at the capability level — is ongoing. The CHERI team has proposed a “capability revocation bitmap” that tracks which memory pages contain capabilities, reducing the scanning overhead from O(total memory) to O(live capabilities), but this has not yet been implemented in hardware.

Capability compression in the memory hierarchy. 128-bit capabilities are twice the size of 64-bit pointers. This increases pressure on caches, memory bandwidth, and on-die interconnects. CHERI Concentrate compresses capabilities for storage in memory, but decompression adds latency to loads. Research on maintaining compressed capabilities deeper in the memory hierarchy — in the L2 and L3 caches, and even in DRAM — could reduce the bandwidth overhead without adding latency to the common case of capability register access.

Verification at scale. As discussed, verifying a full production processor against the CHERI specification remains beyond the state of the art in formal methods. Research on compositional verification, where each microarchitectural unit is verified independently and the composition proofs are automated, could bridge this gap. The Kami project at MIT and the Verifiable CHERI project at Cambridge are pursuing this.

CHERI + safe languages. CHERI provides safety for unsafe code. But what about safe languages that compile to CHERI? Rust, for example, already provides memory safety through its type system. What does CHERI add for Rust code? The answer is defense in depth: if there is a bug in the Rust compiler (and compilers are large, complex programs that do have bugs), CHERI provides a hardware backstop that prevents the generated code from violating memory safety. Research on compiling Rust to CHERI with minimal overhead — leveraging the fact that the compiler knows the bounds of every pointer at compile time and can emit precise capabilities — is an active area.

10. Summary

CHERI is the most serious attempt in a generation to fix memory safety at the hardware level. It replaces flat pointers with capabilities — unforgeable, bounded, permissioned tokens — and enforces spatial memory safety deterministically on every memory access. With the load barrier and sweeping revocation, it provides a practical (though not perfect) solution to temporal safety. The Arm Morello prototype has demonstrated that the approach works with real software, at scale, with acceptable overhead.

The challenges ahead are not primarily technical — the technical foundations are solid — but economic and ecological. Can the CHERI Alliance convince processor vendors to include capability hardware in production chips? Can the software ecosystem — compilers, operating systems, libraries — be adapted to support CHERI without fragmenting? And can the formal verification community deliver the assurance that CHERI’s guarantees hold at the gate level, not just at the ISA specification level?

I am optimistic, but with the caveat that hardware security features have a poor track record of adoption. Intel MPX failed. AMD’s SEV (Secure Encrypted Virtualization) has been broken multiple times. ARM’s PAC (Pointer Authentication) is seeing adoption but provides weaker guarantees than CHERI. The difference with CHERI is that it addresses the root cause — the flat address space — rather than adding a bandage on top. And as the cost of memory safety bugs continues to mount — in ransomware payments, in data breach penalties, in the sheer engineering effort of endless patching — the economic case for a hardware solution becomes harder to ignore.

CHERI may not be the final answer to memory safety, but it is the best answer we have today. And if it succeeds, it will represent the most significant change to the programmer’s model of memory since virtual memory was introduced in the 1960s.

Let me close with a thought experiment. Imagine a world where every processor — from the microcontroller in your thermostat to the server chip in a cloud data center — enforces capability-based memory safety. In that world, buffer overflows do not exist as an attack vector. Use-after-free is a recoverable exception, not a privilege escalation. ROP and JOP are historical curiosities, like the Morris worm’s gets() overflow. Software engineers spend their time on logic bugs — which are hard enough — rather than on the endless cat-and-mouse game of memory corruption. This world is technically achievable. The question is whether we, as an industry, have the collective will to build it. CHERI shows us the path. The rest is engineering, economics, and time.