Skip to content
STIMSMITH

Capability Hardware Security

Concept WIKI v1 · 6/8/2026

Capability hardware security refers to ISA-level approaches in which processor hardware enforces memory protection and authority by requiring capabilities (unforgeable tokens of authority) to be presented on each memory access. The most prominent contemporary example is the CHERI (Capability Hardware Enhanced RISC Instructions) ISA, which augments an existing architecture (originally MIPS, now also RISC-V via the Piccolo/Flute/Toooba cores, and Arm via the Morello research prototype) so that pointers are replaced or accompanied by capabilities carrying bounds, permissions, and other provenance metadata. Capability hardware security is contrasted with coarser hardware mechanisms such as Memory Protection Units (MPUs) and RISC-V Physical Memory Protection (PMP), and is positioned as a way to retrofit spatial safety to existing C and C++ code.

Definition

Capability hardware security is the class of processor designs that enforce memory safety and authority at the hardware level by requiring code to possess and present a capability (an unforgeable, hardware-protected token) for every memory access. Rather than relying solely on virtual-memory-based privilege rings, the capability itself carries the address, bounds, and permissions that the hardware checks on use. The defining property is that the intended capability must be quoted on access, so the executing code's authority is explicit and decentralised, rather than inferred from a global configuration.

CHERI as the Canonical Example

The CHERI ISA is the reference implementation of capability hardware security. In CHERI, ordinary pointers are replaced (or augmented) by capabilities that include bounds and permission bits, and the hardware traps any access that violates those fields. The thesis document UCAM-CL-TR-984 frames CHERI as "hardware enforcing properties inferred from the programmer's code".

CHERI was first demonstrated on a MIPS processor, but UCAM-CL-TR-984 adapts it to RISC-V, motivated by RISC-V's openness and growing research adoption. In parallel, Arm's Morello program produced a research prototype of a CHERI-augmented high-performance core, indicating that capability hardware security is being explored across multiple contemporary ISAs. Three concrete RISC-V instantiations are discussed in the hypotheses section: Piccolo (microcontroller class), Flute (mid-range), and Toooba (application class, out-of-order superscalar), which together span the microcontroller-to-server spectrum.

Comparison with Physical Memory Protection (PMP / MPU)

Capability hardware security is most usefully understood in contrast to the Physical Memory Protection (PMP) mechanism found on RISC-V and the more general Memory Protection Unit (MPU) used on MMU-less embedded cores. The key contrasts drawn in UCAM-CL-TR-984 §2.2.1.2 are:

  • Granularity. A PMP exposes a fixed set of regions (16 or 64 entries depending on implementation) configured through Control and Status Registers (CSRs). Capabilities, by contrast, can be created with arbitrary bounds and can be as fine-grained as the application requires.
  • Intentionality. PMP performs no check that the executing code intended to access a region; it enforces a global set of permitted regions. Capabilities require the intended capability to be quoted, so accesses are bound to the authority the calling code actually holds.
  • Delegation and compartmentalisation. Different access rights to the same physical region cannot be delegated to different compartments under PMP without reconfiguring the PMP on every context switch, because access control is global. Capabilities can be copied and narrowed to grant per-compartment views without disturbing other compartments.
  • Privilege of reconfiguration. PMP entries can only be modified in machine mode, so user code cannot protect itself. Capabilities can be manipulated by user code within the bounds of its existing authority.
  • Lookup cost. PMP performs an associative lookup across all configured regions on every access, and its area and power cost scale linearly with the number of PMP registers. Capabilities avoid associative lookups because the relevant authority is named by the capability being used.
  • Revocation. Revocation is simpler under PMP — one need only add a PMP entry that denies the region. In a capability system, revocation requires guaranteeing that no outstanding capability to the region exists, typically by scanning or maintaining a global invariant, because authority is decentralised.
  • Compatibility with existing code. PMP can protect existing binaries unchanged. Capabilities, in their full form, require at least recompilation (and often source modification) to provide their strongest guarantees.
  • Authority centralisation. PMP centralises authority in a small set of configuration CSRs, which is why reasoning about security and revocation is straightforward but expressive power is limited. Capability hardware decentralises authority, which is more expressive but can make global security reasoning and revocation harder.

The document concludes that the security offered by PMP is a subset of what capabilities provide: PMP can restrict which regions are accessible, but it cannot express per-compartment authority at fine granularity.

Relationship to Spatial Safety and Language-Level Approaches

Capability hardware security is presented as one of three strategies for achieving spatial safety in systems written in C and C++. The other two are:

  1. Hardware memory protection (MMU, MPU, PMP). Provides isolation between processes but, on its own, does not give fine-grained, per-pointer spatial safety inside a single process.
  2. Safe languages. Languages such as Java, C#, and Python obtain spatial safety through dynamic bounds checks, runtime length metadata, and managed-runtime pointer treatment. UCAM-CL-TR-984 notes that even if a universally adopted safe language emerged, billions of lines of critical C and C++ code are already deployed and will continue to be relied upon until replaced, which motivates retrofitting safety onto C/C++ rather than waiting for language change.

Capability hardware security is positioned as a way to obtain language-like spatial safety guarantees for existing C and C++ code by changing the hardware and compiler, leaving source code largely unchanged in style.

Stated Hypotheses About Capability Hardware Security

UCAM-CL-TR-984 articulates four working hypotheses about the feasibility and cost of capability hardware security when retargeted to RISC-V:

  • H.1. CHERI can provide spatial safety for RISC-V microcontrollers with small area, power, clock-frequency, and performance impact.
  • H.2. CHERI can provide spatial safety for RISC-V out-of-order superscalar application-class cores, with small area, power, clock-frequency, and performance impact, despite the need to integrate with load/store queues, reorder buffers, multiple pipelines, and deep speculation.
  • H.3. The area, power, and performance impact of CHERI becomes less significant for larger cores, because capability-related structures (register file, datapath) are a smaller fraction of the core, while unmodified structures (floating point, caches, branch prediction) dominate.
  • H.4. Temporal safety (a class of memory safety less naturally addressed by capabilities alone) can be implemented efficiently atop CHERI for RISC-V.

These hypotheses frame capability hardware security as a scalable design point: cheap enough for microcontrollers, expressive enough for application-class cores, and a useful substrate for additional safety properties beyond pure capability checks.

Implications for Microarchitecture

Because capability hardware security changes the meaning and width of pointer-like values, it interacts with several microarchitectural structures. UCAM-CL-TR-984 notes that adapting CHERI to RISC-V raises open questions about composition with advanced microarchitectural techniques used in contemporary processors, including load/store queues, reorder buffers, and deep speculation in out-of-order designs, where the speculative nature of accesses may diminish CHERI's effectiveness. Conversely, on microcontroller-class cores the central design question is whether the additional logic (tag bits, bounds checks, capability ALU paths) fits within the area, power, and timing budget of small embedded designs.

See Also

LINKED ENTITIES

1 links
UCAM-CL-TR-984 USES

CITATIONS

10 sources
10 citations
[1] Capability hardware security is exemplified by CHERI, which is described as 'hardware enforcing properties inferred from the programmer's code'. UCAM-CL-TR-984.pdf (CHERI on RISC-V thesis)
[2] CHERI was originally demonstrated on a MIPS processor and is being adapted to RISC-V (Piccolo, Flute, Toooba) and to Arm through the Morello research prototype. UCAM-CL-TR-984.pdf (CHERI on RISC-V thesis)
[3] RISC-V Physical Memory Protection (PMP) is a fixed set of CSRs (16 or 64 entries depending on implementation) that restrict read, write, and execute access to memory regions and can only be changed in machine mode. UCAM-CL-TR-984.pdf (CHERI on RISC-V thesis), §2.2.1.2
[4] The security offered by the PMP mechanism is a strict subset of that offered by capabilities: PMP restricts region access only on coarse granularity, lacks intentionality, and cannot delegate different access rights to the same physical region to different compartments without reconfiguration on every context switch. UCAM-CL-TR-984.pdf (CHERI on RISC-V thesis), §2.2.1.2
[5] PMP must perform an associative lookup on every access, incurring area and power cost that grows linearly with the number of PMP registers, whereas capabilities avoid associative lookups by requiring the intended capability to be quoted on access. UCAM-CL-TR-984.pdf (CHERI on RISC-V thesis), §2.2.1.2
[6] Revocation is simpler under PMP (add a PMP entry to forbid a region) but requires scanning or maintaining an invariant in a capability system, because authority is decentralised and capabilities to a region may exist in many places. UCAM-CL-TR-984.pdf (CHERI on RISC-V thesis), §2.2.1.2
[7] Capabilities require at least recompilation of code to provide their full protections, whereas PMP can be used to protect existing binaries unchanged. UCAM-CL-TR-984.pdf (CHERI on RISC-V thesis), §2.2.1.2
[8] Memory Protection Units (MPUs) implement a subset of MMU privilege-protection mechanisms without translation, and can be composed with MMUs to protect machine-mode code; some RISC-V cores offer a standardised MPU that RISC-V calls a PMP. UCAM-CL-TR-984.pdf (CHERI on RISC-V thesis), §2.2.1.2
[9] Capability hardware security is one of three strategies for spatial safety in C and C++: hardware memory protection, safe languages (Java, C#, Python using dynamic bounds checks), and capabilities (CHERI). The document notes that even a universally adopted safe language would not displace billions of lines of existing critical C and C++ code, motivating the hardware-capability approach. UCAM-CL-TR-984.pdf (CHERI on RISC-V thesis), §2.2.1.3
[10] The thesis articulates four hypotheses (H.1–H.4) that capability hardware security via CHERI can be applied with small overheads to RISC-V microcontrollers (H.1), to out-of-order superscalar application-class cores (H.2), that overheads decrease as cores grow (H.3), and that temporal safety can be efficiently added atop CHERI (H.4). UCAM-CL-TR-984.pdf (CHERI on RISC-V thesis), §1.2