Skip to content

CHERI (Next Generation)

CHERI (Next Generation)

memory-safety hardware

Hardware capabilities: 128-bit fat pointers with bounds, permissions and an out-of-band tag, enforced by the ISA.

§1 Provenance

§2 Mechanism

CHERI replaces 64-bit native pointers with 128-bit capabilities held in extended general-purpose registers (a “merged” file in ISAv9; previous versions had split files). Each capability carries:

  • a 64-bit address/cursor (the value the program uses)
  • compressed bounds (lower, upper) stored in ~28 bits using a floating-point-style mantissa+exponent scheme (CHERI Concentrate); on ISAv9 mantissa width MW=14 with two derived bits
  • permissions (load, store, execute, load-cap, store-cap, store-local-cap, seal, unseal, system-regs, etc.), typically ~18 bits split into hw-defined and sw-defined fields
  • object type / otype (~16 bits) for sealed-capability compartmentalisation
  • a flag bit and CP control bits

A separate 1-bit tag travels with every 128-bit memory granule through caches and DRAM in a sideband. Any non-capability store to a granule clears its tag. The tag is invisible to load/store instructions and cannot be forged in software; it is what distinguishes a real capability from arbitrary data.

Loads/stores accept a capability operand, the hardware decompresses the bounds in parallel with TLB translation, and any access outside [base, top) or violating permissions raises a CHERI exception. Branches and indirect calls require a capability with Execute permission (PCC is itself a capability). Bounds are monotonic: a CSetBounds instruction may only shrink, not grow. Per ISAv9 (a Morello-influenced decision), attempted non-monotonic modification clears the tag rather than trapping, which simplifies generic code that doesn’t know if a value is a capability.

Sealing (CSeal/CUnseal) freezes a capability so it can only be invoked through a controlled entry point (CCall/sentry); this is the substrate for compartments.

§3 Threat model + guarantees

  • Spatial safety: deterministic per-pointer bounds; linear and non-linear OOB writes are stopped at the ISA boundary, including DMA on CHERI-enabled fabrics.
  • Pointer integrity / provenance: untagged data cannot be dereferenced. An attacker who corrupts a capability in memory clears the tag; the next load-via-cap traps.
  • Compartmentalisation: sealed caps + per-thread DDC/PCC support millions of in-process compartments with cheaper boundary crossings than process isolation.
  • Temporal safety (partial): CHERI itself does not prevent UAF; you still need a revocation mechanism (CHERIvoke, Cornucopia Reloaded, CHERIoT’s load-barrier+sweep). With revocation deployed, UAF is closed deterministically.
  • Type confusion: not addressed by the ISA; addressed by language-level use of sealed caps and refined types in CHERI-C++.
  • Control-flow: sealed entry points + bounded PCC kill arbitrary ROP/JOP within a compartment, but in-compartment ROP is still possible.
  • Side channels: CHERI tags ride normal cache lines, so cache and timing side channels remain. TIKTAG-style attacks against MTE do not directly apply, but other Spectre variants do.
  • Not protected: information leaks (the tag is integrity, not confidentiality), uninitialised reads (see Mon CHÉRI / conditional caps research), supply-chain bugs, logic flaws.

§4 Production status (May 2026)

  • Codasip X730 (rebrand of A730-CHERI) is the first commercial CHERI-RISC-V application core, licensable since April 2025, shipped on the “Codasip Prime” FPGA exploration platform; the register file extends to 129 bits to carry capabilities.
  • CHERI Alliance (founded mid-2024) includes Cambridge, Arm, Codasip, Google, Microsoft, lowRISC, SCI Semiconductor, NCSC, Dstl.
  • Arm Morello prototype (Neoverse N1 + CHERI) shipped several hundred boards 2022-2024; DSbD program closed-out Oct 2025 with a £200M spend, 405 jobs, 80% positive evaluation from TAP participants, and a programme-level claim that DSbD-style hardware would mitigate ~70% of known memory-safety CVEs.
  • Microsoft CHERIoT ISA v1.0 frozen 2024; SCI Semiconductor ICENI (CHERIoT-Ibex) tapeout in 22nm, first commercial silicon H2 2025, with lowRISC’s Sonata FPGA board distributed via Mouser through 2025-2026.
  • Vendor commitments: NCSC, Google and Microsoft publicly endorse CHERI for high-assurance embedded use; no full-CHERI server CPU is yet on a public roadmap as of May 2026.

§5 Software emulation cost

A pure-software CHERI emulation (e.g. CheriABI on QEMU; or sketches that store fat-pointer metadata next to each pointer) typically pays:

  • 2x pointer footprint (cache pressure ~20-30% on pointer-heavy workloads)
  • per-deref bounds + permission check in software: 5-15% on bounds checks alone, more if revocation is added
  • tag tracking requires either a shadow map (1 bit per 16 B of address space, ~0.8% RAM but every store must update it, ~30-100% slowdown for naive impls) or per-allocation metadata.

Reported numbers from MorelloBSD on Morello hardware are <5% on most SPEC subprograms; the same protection in software (Softbound+CETS, Low-Fat Pointers, EffectiveSan) historically lands at 1.5x-3x runtime and 1.5x-2x memory. CHERIvoke revocation adds ~5% on hardware, ~25-50% in software.

§6 Mochi adaptation note

vm3’s Cell is already a “software CHERI lite”:

CHERI 128-bit capvm3 Cell (8 B)
64-bit cursorimplicit: arena+idx encode an address
compressed boundsimplicit: per-slab fixed-size slots, bounds=slot size
1-bit out-of-band tagthe 12-bit generation carried in-band
permissions (~18 bits)4-bit arena tag (read-only on const arena, etc.)
otype (~16 bits)not present
monotonic boundstrivially true: vm3 cells never re-bound

What MEP-40 already gives us (per the handle layout doc): spatial safety inside a slab is automatic because the slab index times a fixed slot size cannot escape the slab; provenance/integrity is the generation check. We are stronger than CHERI on monotonicity (we cannot widen) and weaker on permissions (arena tag has 16 possible values, CHERI has ~18 bits).

The smallest gap-closer for MEP-41 is a permissions field carved out of the 32-bit slab index (e.g. take 4-6 bits of the high end of the slab index for perm once we cap slabs at 16-26 bits of slots; we lose some range but gain read-only / no-cap-store / no-execute distinctions). This is the software analogue of CHERI’s permission word, and it composes with MEP-15 effects (an effect-typed handle can be downgraded to no-write at runtime).

No sealing analogue today. Compartments (MEP-15 effect domains) currently rely on the type system, not on handle metadata. If we wanted in-process least-privilege compartments without language-level cooperation, a 1-bit “sealed” flag + a 4-bit “otype” inside the arena-tag byte would suffice for a small number of compartments.

§7 Open questions for MEP-41 design

  1. Do we want a fixed-shape Cell forever, or a “wide handle” variant (16 B) for compartmentalised code, similar to how CHERI runs both 64- and 128-bit modes on Morello?
  2. If we add a permissions field, do we let the compiler narrow it at known-safe call sites (like CHERI’s CAndPerm), and how do we keep the generation-check fast?
  3. Should the arena tag also carry a colour for revocation sweeps (à la CHERIoT’s load-barrier), or do we rely entirely on bump-generation for temporal safety?
  4. Sealing: do MEP-15 effect handles need ISA-level sealing, or is per-effect arena assignment sufficient?
  5. How do we expose CHERI hardware when present (Morello / X730 / ICENI)? Can the vm3 backend lower a Cell directly to a 128-bit capability and inherit hardware spatial safety for free?