Overview

CHERI stands for Capability Hardware Enhanced RISC Instructions. It is a hardware-supported memory-safety architecture, developed from a 2010 University of Cambridge project, that extends existing instruction-set architectures with architectural capabilities rather than replacing them wholesale. Public evidence describes CHERI as a leading hardware/software system that provides native spatial safety and a foundation for temporal memory safety, and as the most mature capability-based memory-safety architecture. It has been implemented and evaluated across multiple platforms including software-based emulation, FPGA prototypes, and ASICs such as Arm's Morello. [CHERI-D characterization] [DDECS 2026 framing]

CHERI addresses memory-safety problems such as buffer overflows and use-after-free vulnerabilities, which are framed in the evidence as a major source of security vulnerabilities and motivate hardware-supported memory-safety mechanisms where software-only mitigations are described as partial and costly. The DDECS 2026 paper situates CHERI among hardware-assisted spatial and temporal memory-safety techniques alongside bounds-checking mechanisms such as HardBound and SoftBound, tagged-memory architectures such as ARM Memory Tagging Extension, and other capability-based systems. [Memory-safety motivation]

The RISC-V community is in the process of standardizing CHERI extensions, and CHERI's unforgeable hardware capabilities for memory safety and compartmentalization are explicitly noted as the property under test when the architecture is deployed on RISC-V processors. [CHERI in TestRIG poster]

Capability model

CHERI introduces capabilities as architectural primitives that compilers, systems software, and applications use to constrain their own future execution. In CHERI systems, traditional program pointers are replaced or represented by capabilities: pointer-like values that extend integer memory addresses with metadata controlling how the referenced object may be used. [Capability model]

The capability metadata includes bounds and permissions; the bounds encode base and top information, and permissions allow fine-grained memory protection such as load, store, and execute access. CHERI capability bounds are used to prevent out-of-bounds memory access, and the architecture enforces strict bounds, permission, and validity checks on memory accesses. [Capability metadata]

Tags, tagged memory, and integrity

CHERI uses an out-of-band tag bit associated with capabilities that is stored separately from normal data, is atomically bound to the capability, and validates the capability. The tag can be read and unset by software but cannot be set by software, and records each capability's authenticity. [Capability tag bit]

At the hardware level, CHERI extends the protection mechanism beyond registers: general-purpose registers become capability-carrying registers, the program counter is extended with a capability, and tagged memory protects capability-sized and capability-aligned words in DRAM by adding validity tags. CHERI maintains capability validity using tag bits stored in a dedicated, non-addressable tag memory; during capability store instructions such as sc.ddc and sc.cap, the corresponding tag bit must be updated alongside the data. [Tagged memory and tag-update mechanism]

CHERI instructions enforce monotonicity and guarded manipulation, meaning capability transformations are constrained by the architecture rather than allowing arbitrary construction of authority-bearing pointers. [Guarded manipulation]

CHERI checks may run on capabilities whose integrity tag is already clear, which means a CHERI check can be executed without ever detecting an error and hides the bug from naive code-coverage metrics; this observation motivates mutation-based coverage for CHERI verification. [Integrity tag and coverage caveat]

Hybrid execution

The CHERI capability format includes a flag_cap_mode flag that is required in hybrid mode, where CHERI-aware and legacy code can run side by side. A separate allocator study examined allocators running under both hybrid and pure-capability modes on CheriBSD on Arm's experimental Morello platform and cautioned that comparing allocator performance between these modes did not appear meaningful in that evaluation. [Hybrid mode]

Software and platform ecosystem

CHERI has grown into an ecosystem of hardware, software, and tools, including an adapted LLVM compiler and CheriBSD, a CHERI-enabled FreeBSD operating system. CheriBSD has been used to boot on a CHERI-RISC-V virtual prototype and to demonstrate enforcement of CHERI memory protection: in a read-beyond-bounds test under CheriBSD, the operating system killed the offending program while the system continued running. [CHERI ecosystem] [CheriBSD VP case study]

A CHERI-RISC-V virtual-prototyping effort extends the RISC-V VP++ platform to provide a SystemC/TLM virtual prototype for CHERI-RISC-V system-level evaluation. The DDECS 2026 evaluation integrates the CHERI extension for RISC-V into an open-source RISC-V VP, applies generated benchmarks to both a baseline CHERI VP and an extended VP modeling an in-memory computing (IMC) acceleration of the tag-update mechanism, and uses network sockets to communicate between TestRIG and the design under verification. [RISC-V VP integration]

Verification of CHERI processors with TestRIG

TestRIG is an ecosystem for cross-verifying RISC-V implementations using a standard RVFI-DII interface. Verification Engines connect to the implementations over this interface, and QuickCheckVEngine uses Haskell's QuickCheck library to generate tests and automatically shrink any divergences to a minimal reproducer. The RISC-V golden Sail model implements RVFI-DII, allowing implementations to be compared against this executable simulator. [TestRIG overview]

Since initial publication, the TestRIG infrastructure has seen increasing community engagement, including users and contributors from Microsoft Research, lowRISC, and SCI Semiconductor. The TestRIG repository now links to 10 RVFI-DII-extended implementations, and has several forks from other members of the community. [TestRIG community engagement]

TestRIG is in use to test CHERI in the Toooba and CVA6 processors, and the project URL is cheri-cpu.org. [CHERI under test]

For coverage, measuring lines of code run is insufficient because code may run without affecting tested outputs; for example, CHERI checks may be exercised on capabilities whose integrity tag is already clear, hiding the error. The TestRIG tooling instead uses mutation coverage: it simulates real bugs by modifying the Sail code with incorrect behavior, automatically tries classes of common mistakes, and answers whether the test framework would have caught a given bug. Currently supported mutation types include deleting "encdec" mappings (asserting "every instruction tested"), deleting code lines (asserting "every side effect tested"), and replacing branch conditions (asserting "every behavior tested"). [Mutation coverage]

TestRIG also supports a single-implementation mode that runs an implementation on its own and asserts more liberal properties over the RVFI trace, such as that the number of instructions in equals the number of instructions out (i.e., the processor did not lock up). This mode relies on DII to allow testing without having to reason about control flow. Template-based undirected random instructions are used to find and diagnose issues such as processors mis-decoding and locking up on certain illegal instructions, subtle and rare compressed-branch mispredict infinite loops, and reachable fatal assert conditions in versions of the Sail model. [Single-implementation mode]

Security-aware early benchmarks

The DDECS 2026 paper introduces a framework for generating security-aware instruction-level benchmarks for CHERI-enabled architectures that are available early in the system development cycle, before mature software stacks such as CheriBSD are available. The benchmark generation workflow combines TestRIG-based random instruction generation with security-aware post-processing, then combines the processed instruction streams with platform-specific bootstrap code to build executable benchmarks, and finally evaluates them on virtual prototypes. [Benchmark generation framework]

Because raw TestRIG instruction streams are intended for functional verification and intentionally violate architectural invariants, the framework filters generated streams to remove instructions that would trap or terminate execution on a correct RISC-V CHERI implementation, and then post-processes them to enforce proper capability preparation and usage. The post-processing inserts or rewrites instruction sequences to construct capabilities with appropriate bounds, permissions, and tags, so that capability instructions execute successfully and reach CHERI-specific hardware such as the tagged memory. [Security-aware instruction processing]

Instruction distributions can be further controlled through TestRIG's generation parameters, allowing the benchmarks to emphasize specific CHERI instructions or approximate application-level behavior, enabling targeted and reproducible performance evaluation of CHERI microarchitectures. The framework is intended to enable concurrent evaluation of performance and security correctness during system development. [Configurable benchmark distributions]

IMC-based tag-update case study

As an illustrative case study, the DDECS 2026 paper models an IMC-based acceleration of the CHERI tag-update mechanism. A conventional implementation transfers the tag-containing memory word to the processor, modifies the tag, and writes it back, incurring additional memory traffic and latency; the IMC-based model performs tag updates directly within the memory array, allowing the processor to issue a tag-modification command without transferring full memory words. The latency of the in-memory tag update operation (IMC-time) is parametrized from 0 ns to 30 ns, and three benchmarks with accelerated instruction occurrences ranging from 8 % to 20 % (TRG_8, TRG_15, TRG_20) demonstrate the configurability of the benchmark generation. For an idealized IMC-time of 0 ns, normalized speed-ups between 1.06× and 1.11× are observed, while acceleration becomes ineffective for latencies above approximately 20 ns. [IMC-based tag-update case study]

Memory-safety research built on CHERI

Public research treats CHERI as a leading hardware/software system for memory safety. The CHERI-D proposal characterizes CHERI as providing native spatial safety and a foundation for temporal memory safety, but notes that CHERI lacks intrinsic architectural support for temporal memory safety. CHERI-D proposes associating object-ID metadata with capability pointers to provide temporal integrity of allocations and reports reduced revocation overhead versus Cornucopia Reloaded while supporting strict use-after-free mitigation. [CHERI-D temporal safety]

A public allocator study reports that several open-source memory allocators were ported to CHERI and evaluated under CheriBSD on Arm's experimental Morello platform. The study introduced security attacks and found that all but one allocator were vulnerable to at least some attacks, including the default CheriBSD allocator; it also cautioned that comparing allocator performance between hybrid and pure-capability modes did not appear meaningful in that evaluation. [CHERI allocator study]

Related concepts

• capability pointer: CHERI uses capability pointers in place of traditional pointers to carry authority and metadata. [Capability model]
• tagged memory: CHERI uses tagged memory to preserve validity tags for capabilities stored in DRAM. [Tagged memory and tag-update mechanism]
• capability bounds: CHERI bounds encode base/top information and are enforced on memory access. [Capability metadata]
• capability permissions: CHERI permissions express fine-grained rights such as load, store, and execute. [Capability metadata]
• capability tag bit: CHERI uses an out-of-band tag bit to validate capability authenticity. [Capability tag bit]
• hybrid mode: CHERI hybrid mode permits CHERI-aware and legacy code to run side by side. [Hybrid mode]
• TestRIG: a randomized tandem-verification ecosystem for RISC-V, used to test CHERI in the Toooba and CVA6 processors. [TestRIG overview] [CHERI under test]
• mutation coverage: a TestRIG technique that mutates the Sail golden model to assess whether the test framework would catch real CHERI bugs. [Mutation coverage]
• security-aware early benchmarks: instruction-level benchmarks for CHERI generated by post-processing TestRIG output to construct valid capabilities and exercise tagged memory. [Benchmark generation framework] [Security-aware instruction processing]