On every mainstream machine, a C pointer is represented as a bare integer address. That single fact is at the root of an enormous share of the security vulnerabilities ever shipped: nothing in the representation says what the pointer is allowed to reach.
CHERI (Capability Hardware Enhanced RISC Instructions) makes a pointer a capability instead: an address, plus bounds, plus permissions, plus a validity tag, with the hardware enforcing all of it on every dereference.
What that buys you¶
A buffer overflow stops being a memory-safety bug and becomes a trap. Not spotted afterwards by a sanitiser, not caught now and then by a canary; refused in hardware, because the processor won't perform an access outside the bounds.
The tag is the clever part. It's a bit held outside the addressable data and maintained by the hardware, and it drops to zero if the capability is manipulated with ordinary arithmetic. You can't forge a capability by constructing an integer. Provenance is therefore unforgeable: a capability can only be derived from another with equal or lesser rights.
That property, monotonic non-increase of authority, is what makes CHERI a capability system rather than bounds-checked pointers with better marketing.
Where it is today¶
The RISC-V CHERI specification is not ratified. The most recent version we can find is an intermediate release, v0.9.10.1, dated 2026-10-14 (riscv/riscv-cheri releases). Hot Chips 2026 coverage lists CHERI among work-in-progress items. The base is designated RV64Y.
There's also a compatibility wrinkle: Zicfiss is incompatible at present, because its shadow-stack push and pop instructions would need modifying for CHERI.
Arm's Morello was a research prototype of the same ideas on ARMv8 and produced real evaluation results. It was a research platform, not a product line.
So: promising, extensively researched, demonstrably implementable and not something you can buy and deploy.
What it would cost¶
- Pointers get bigger. A 128-bit capability where a 64-bit pointer used to be. On pointer-dense workloads that's cache pressure you'll feel.
- Source changes are needed. Not a recompile. Code that stores pointers in integers, does its own tagging in spare bits or reconstructs pointers from arithmetic (all common in systems code) has to change.
- The whole stack has to agree. A capability-aware kernel, a capability-aware libc and a capability-aware compiler. You don't get to do this one layer at a time.
The prize is larger than the coverage suggests, and it is not only a security prize. Roughly two thirds of serious vulnerabilities in systems software are memory safety. The industry's answer so far is to rewrite in a safe language, which works and which will take thirty years, because the C and C++ in service is measured in billions of lines and most of it has no owner. CHERI is the other route: keep the code, recompile it and have the hardware refuse the access.
Be precise about which half that is. A recompile buys spatial safety: every pointer carries its bounds and its permissions, so a read or write outside the object it was derived from is refused by the hardware. That is the buffer-overflow family, and it is most of the historical catalogue.
It does not, on its own, buy temporal safety. A pointer to freed memory is still a valid capability until something invalidates it, and use-after-free is half of Chromium's high-severity memory bugs. The answer is capability revocation: sweeping memory for capabilities to freed regions, as CHERIvoke and Cornucopia do. That is a real cost, paid at runtime, on top of the recompile. It is the unfinished half, and anyone selling CHERI as the end of memory unsafety is selling the easy part.
The second-order effect is the one we would watch. A crash is a bug report; a breach is an incident, a disclosure, a regulator and a fortnight. The economics of maintaining old software change completely once its worst failure mode is downtime. A great deal of working equipment then gets to keep working safely instead of being replaced for security reasons. That is a repairability and a waste argument as much as a security one, and nobody makes it.
For engineering itself the win is debugging. A capability violation traps at the instruction that did it, with bounds attached. Compare the current experience: memory corrupted at ten in the morning, crash at four in the afternoon, somewhere else entirely, in innocent code. The bug class that disappears is the one where symptom and cause have nothing to do with each other, and it is the most expensive class there is.
Compartmentalisation is what the research community cares about most, and it is furthest from deployment. Cheap unforgeable capabilities let you split a large program into mutually distrusting parts without processes or IPC costs: the image decoder in a browser, the parser in a mail server, each holding only the memory it was handed.
The new boundary moves the chokepoint to intellectual property.
CHERI came out of Cambridge and SRI, with substantial public funding, and the research is published. The question that decides whether it becomes infrastructure or a feature: can anybody implement it, or only those who can do a deal with Arm?
Both routes are live at once. The RISC-V extension, if it ratifies, is implementable by anyone who can make a chip; that is the version where a small vendor, a university or a state-funded programme can build capability hardware without asking permission. The Arm route reaches far more devices far sooner, because Arm is in everything, and on Arm's licensing terms and schedule. Morello was a research prototype; whether the ideas reach a shipping Arm architecture, in what form and under what terms, is Arm's commercial decision rather than a technical one.
Watch for the version that is worst for everybody: memory safety as a premium architectural feature. Available in the high-margin parts, absent from the cheap ones, so the devices hardest to patch and longest-lived in the field (the meter, the camera, the controller in a building) keep shipping the unsafe pointer while phones and servers get the protection. Security stratified by unit price, with the exposure concentrated where nobody is maintaining the software. The cost is not nothing: doubling pointer width pushes on cache and memory bandwidth, as above, and the tag bits have to be carried through the whole hierarchy. But it is a one-off silicon and bandwidth cost rather than a per-unit licence. It will land in the premium tier anyway if the only licensable implementation is a premium one.
The specification work is happening in the open in RISC-V, and the compiler and kernel work exists as open source from the research programme. Here at AxisOps our position is that publicly funded memory safety ought to be universally implementable, and the test is simple: if a chip designer with no Arm relationship cannot build it, the public money bought a competitive advantage rather than a public good.
Where it sits among the strands¶
CHERI is the hardware answer to the same problem eBPF solves with a verifier and WASM solves with validation.
The software approaches check once at load time, after which the crossing costs nothing even though the checked code still costs what it costs. They are limited to code they can analyse. CHERI checks on every dereference, in hardware, with no analysis needed and no language restriction; the price is new silicon and a recompiled world. Neither is strictly better: they're the same instinct (make authority explicit and unforgeable) applied at different points in the stack.