Skip to content
STIMSMITH

Capability Permissions

Concept WIKI v1 · 6/21/2026

Capability permissions are a category of in-band metadata carried by CHERI capability values that govern which operations (such as Load, Store, or Execute) a capability authorizes. Together with bounds and object-type fields, permissions provide the fine-grained, hardware-enforced memory protection that distinguishes CHERI capabilities from plain integer memory addresses.

Overview

In the CHERI capability-based architecture, a capability is an unforgeable, 128-bit token that replaces traditional integer memory pointers. Unlike a bare address, a capability carries metadata — including bounds, object type, a validity tag, and permissions — that the hardware consults on every memory operation performed through that capability. The permissions field is the mechanism by which a capability expresses what the holder is allowed to do with the memory it addresses, as distinct from which memory it addresses (the bounds field).

Role within a CHERI capability

A CHERI capability value is composed of several encoded fields:

  • Bounds — compressed encoding of the accessible base and top of the address range.
  • Permissions — a bitmap indicating which operations the capability authorizes.
  • Object type — identifies the kind of object the capability points to (used, for example, to validate object-method invocation by requiring both a Data capability and an Execution capability).
  • Reserved / other metadata fields (e.g., a flag_cap_mode bit required for Hybrid-Mode operation, where CHERI-aware and legacy code coexist).
  • Tag bit — an out-of-band validity tag stored separately and atomically bound to the capability, which validates that the capability has not been forged or corrupted.

The permission bits are checked by the ISA on instruction issue, alongside bounds checks, so unauthorized accesses are trapped rather than silently permitted.

Examples of permissions

Common permission bits enumerated in the CHERI specification and illustrated in the ASP-DAC 2026 paper A RISC-V CHERI VP include:

  • Load — permits reading memory through the capability.
  • Store — permits writing memory through the capability.
  • Execute — permits using the capability to fetch instructions (i.e., an executable capability, necessary in combination with a Data capability to invoke object methods safely).

Because permissions are stored per-capability rather than per-page or per-process, software can mint derived capabilities with a subset of the original permissions (a property called monotonicity), enabling patterns such as handing out a read-only view of a buffer or separating code-fetch rights from data-access rights at function-call boundaries.

Hardware support for permissions

Enforcing capability permissions requires architectural changes throughout the processor and memory system:

  • General-purpose registers widen to 129 bits (a 64-bit address plus 64 bits of metadata such as bounds and permissions, plus a 1-bit tag).
  • The program counter is itself extended with a capability, so instruction-fetch permissions can be checked.
  • Tagged memory protects capability-sized, capability-aligned words in DRAM by associating an out-of-band validity tag.
  • The system bus is extended to transport these out-of-band tags across the memory hierarchy.
  • The ISA is augmented with new instructions for capability manipulation, and existing instructions are modified to enforce monotonicity and guarded manipulation of permission bits.

Relationship to other CHERI concepts

  • CHERI: capability permissions are one of the metadata classes that define the CHERI protection model; without permissions, capabilities would only offer spatial confinement (bounds) without type- or operation-level control.
  • Capability pointer: a capability pointer is the concrete program-visible handle that carries the permissions field; capability permissions extend the meaning of an ordinary pointer by encoding authorized operations in the pointer value itself.

LINKED ENTITIES

2 links
CHERI USES
capability pointer EXTENDS

CITATIONS

5 sources
5 citations
[1] Capabilities extend integer memory addresses to 128 bits and carry metadata (bounds, permissions, …) that controls how the capability may be used, replacing traditional pointers in programs. A RISC-V CHERI VP: Enabling System-Level Evaluation of the Capability-Based CHERI Architecture (ASP-DAC 2026)
[2] CHERI capabilities include a permissions field that allows fine-grained memory protection, with examples such as Load, Store, and Execute. A RISC-V CHERI VP: Enabling System-Level Evaluation of the Capability-Based CHERI Architecture (ASP-DAC 2026)
[3] A capability carries an object-type field that, together with permissions such as the Execute permission, is used to validate object-method invocation by combining a Data capability with an Execution capability. A RISC-V CHERI VP: Enabling System-Level Evaluation of the Capability-Based CHERI Architecture (ASP-DAC 2026)
[4] Capability values include a bounds field (with a relative compression algorithm), a `flag_cap_mode` flag for Hybrid-Mode coexistence of CHERI and legacy code, a tag bit stored out-of-band and atomically bound to the capability, and reserved fields. A RISC-V CHERI VP: Enabling System-Level Evaluation of the Capability-Based CHERI Architecture (ASP-DAC 2026)
[5] CHERI hardware changes to enforce capability permissions and other metadata include 129-bit general-purpose registers (64-bit address + 64-bit metadata + 1-bit validity tag), a capability-extended program counter, tagged memory for capability-aligned words, an extended bus for out-of-band tags, ISA extensions, and instructions that enforce monotonicity and guarded manipulation. A RISC-V CHERI VP: Enabling System-Level Evaluation of the Capability-Based CHERI Architecture (ASP-DAC 2026)