CHERI and Memory-Safe Hardware in 2026: How Capability Chips Stop Buffer Overflows in Silicon, What Arm Morello Proved, and Why It Matters Even If You Never Write C
- Internet Pros Team
- August 28, 2026
- Networking & Security
Roughly seven out of every ten serious security vulnerabilities shipped by large software vendors over the past two decades have come down to the same mistake: a program reading or writing memory it had no business touching. We have tried to fix this with better languages, better compilers, better static analysis and better developers. In 2026 a different approach is finally reaching real silicon, and its argument is blunt. If software cannot be trusted to respect memory boundaries, make the processor enforce them.
The Bug That Never Went Away
A memory safety bug is not exotic. A program allocates room for sixty-four characters, someone supplies two hundred, and the extra bytes land on top of whatever was next in memory. Sometimes that is harmless data. Sometimes it is the address the processor will jump to next, and the attacker has just chosen what your server does for a living.
The industry response has been layered mitigations: stack canaries, non-executable memory, address randomisation, control flow integrity. Each raised the cost of an attack without removing the underlying flaw, and each has been worked around. The deeper problem is architectural. On a conventional processor a pointer is simply an integer. Nothing in the hardware records how large the region it points to is meant to be, or whether that region is still alive. The chip does exactly what it is told, because it has no way of knowing it was told something wrong.
What a Capability Actually Is
CHERI, which stands for Capability Hardware Enhanced RISC Instructions, replaces that plain integer with something the hardware can reason about. A CHERI pointer, called a capability, carries the address plus the bounds of the region it is allowed to reach, a set of permissions such as read, write or execute, and a validity tag held in hardware outside the reach of ordinary instructions.
Two rules do most of the work. The processor refuses any access outside the recorded bounds, and it refuses to let software forge or widen a capability. You can narrow one, handing a function access to a smaller slice of memory than you hold yourself, but you can never manufacture authority you were not given. An overflow does not corrupt the neighbouring data and quietly continue. It becomes a hardware fault at the instant it happens, at the line of code responsible.
Address randomisation makes an attacker guess. Capability hardware makes the guess impossible to act on, because authority cannot be fabricated from a number.
That handles spatial safety, meaning access outside the intended region. The harder half is temporal safety, where memory is freed and a stale pointer is used afterwards. CHERI addresses this by making stale capabilities findable and revocable, because the tags let the system identify every genuine pointer in memory rather than guessing which integers happen to look like addresses.
What Morello Proved
The idea dates to research at Cambridge and SRI, but the milestone that changed the conversation was Morello, a physical Arm prototype board built to test whether capability hardware survives contact with real software rather than benchmarks. The results that mattered were not about performance. They were about scale.
Substantial bodies of existing C and C++, including an operating system and a browser engine, were rebuilt to run on capability hardware with a change rate in the low single digits of a percent of lines. That number is the whole argument. Rewriting decades of infrastructure into a memory-safe language is a generational project. Recompiling it with modest edits is a budget item.
| Attack class | On a conventional chip | On capability hardware |
|---|---|---|
| Buffer overflow | Silently overwrites adjacent memory, often exploitable | Traps immediately at the offending instruction |
| Use after free | Stale pointer still works and can be reclaimed by an attacker | Revoked capability is invalid and cannot be used |
| Pointer forgery | Any integer can be treated as an address | Untagged values are not usable as pointers |
| Return address hijack | Overwritten control data redirects execution | Control data is protected by bounds and permissions |
| Library overreach | A linked dependency shares the whole process address space | Compartments hold only the memory handed to them |
The Second Benefit Nobody Expected
Bounds checking gets the headlines, but compartmentalisation may prove more valuable. Because authority can be narrowed cheaply, a process can hand a third-party library exactly the buffer it needs and nothing else. Today a single compromised dependency inherits the full authority of the application that loaded it, which is precisely why software supply chain attacks are so effective. Capability hardware turns that from a total loss into a contained one, and it does so at a cost measured in nanoseconds rather than the microseconds a separate process would take.
What This Means If You Run a Business, Not a Chip Fab
- You will not buy CHERI. You will inherit it. It arrives inside routers, cameras, industrial controllers and eventually servers, not as a product you evaluate.
- It does not replace secure coding. Logic flaws, weak authentication, exposed admin panels and misconfigured permissions are entirely unaffected.
- Interpreted stacks benefit indirectly. PHP, Python and JavaScript are already memory-managed, but their runtimes, TLS libraries and image parsers are written in C.
- Ask vendors about memory safety roadmaps. Regulators and public sector buyers increasingly expect an answer, and firmware is where the honest ones get uncomfortable.
- Patch discipline still wins today. The vulnerabilities being exploited against you this month are on hardware that has none of this.
The Costs, Stated Honestly
Capabilities are larger than the addresses they replace, so pointer-heavy programs use more memory and put more pressure on caches. Reported overheads vary widely by workload, from negligible to noticeable, and the honest summary is that it depends on how much of your working set is pointers. Silicon area increases. Debuggers, compilers and operating systems all need work. And software that plays games with pointer arithmetic, packing extra information into unused bits, needs real attention rather than a recompile.
There is also a chicken and egg problem that no engineering result solves. Chip vendors want demand before committing area, and software vendors want hardware before committing effort. The embedded world is breaking that deadlock first, because CHERIoT targets small microcontrollers where the area cost is tiny and the security stakes, in devices that ship by the million and are patched approximately never, are enormous.
Where This Actually Stands
Nothing here is speculative research, and nothing here is in your laptop. Capability extensions for RISC-V are progressing through standardisation, Arm has published architectural work beyond the Morello prototype, and embedded implementations are shipping in evaluation silicon. Government guidance in both the United States and the United Kingdom now treats memory safety as a procurement question rather than an engineering preference, which is the sort of pressure that moves roadmaps.
The realistic timeline is years, not quarters, for anything you would deploy in a data centre. What is worth understanding now is the direction of travel: the industry has concluded that a fifty-year-old class of bug will not be trained, audited or rewritten out of existence, and has started asking the hardware to refuse it instead. That is a slower fix than a patch, and a considerably more permanent one.
