Overview
Capability bounds are the address-range metadata fields embedded inside a capability pointer that define the region of memory the capability authorizes its holder to access. They are one of the core metadata components of capability-based protection systems, alongside permissions, an object type, and an out-of-band validity tag, and are the primary mechanism through which CHERI and related architectures enforce fine-grained spatial memory safety.
Role in CHERI Capabilities
In the CHERI capability model, a capability is a 128-bit (or, when including the validity tag, effectively 129-bit) extension of an integer memory address. Capability bounds explicitly encode a base and a top address that delimit the legal address range. The bounds field uses a compression algorithm that stores the range relative to the capability's address, allowing a compact representation while still authorizing a precise interval of memory.
Hardware (and a CHERI-aware virtual prototype) enforces that any load, store, or other memory access through the capability falls within the encoded bounds; accesses outside the bounds trap. Bounds are manipulated monotonically by CHERI instructions, so they can only ever be narrowed (restricted), never widened, preserving the invariant that a derived capability cannot exceed the authority of the capability from which it was derived.
Composition with Other Capability Metadata
A CHERI capability generally carries several metadata fields in addition to bounds:
- Permissions — fine-grained access rights such as Load, Store, Execute.
- Object type — the type of object the capability references; for example, enabling validation of object method invocation by combining a data capability with an execution capability.
- Reserved bits — for architectural extensions.
- Validity tag — an out-of-band bit stored separately from normal data and atomically bound to the capability word, validating its integrity and preventing forged capabilities.
Bounds are the spatial component of this metadata: they constrain where in memory the capability may be used, while permissions constrain how.
Delegation via Bounds
Because bounds can be narrowed but never widened, they provide a natural mechanism for hierarchical delegation. An allocator can derive a sub-capability with tighter bounds covering only the region it wishes to hand to a consumer; the consumer cannot use that capability to reach memory outside the narrowed range, even if it possesses a malicious or buggy code path. PoisonCap builds on this property by delegating memory-poisoning privilege using capability bounds, allowing nested allocators to enforce temporal safety on their consumers without disturbing upstream allocators.
Capability-Indexed Composition
In formal models of governed execution, capability-indexed composition bundles programs together with machine-checked capability bounds, and a dual-guarantee theorem establishes that the within-capability and governance-safety predicates hold simultaneously across all composition operators. This usage of bounds is distinct from CHERI hardware but preserves the same intuition: bounds are the authoritative specification of which resources a given program fragment may touch.
See Also
References
- CHERI virtual prototype slides, ASP-DAC 2026
- PoisonCap: Efficient Hierarchical Temporal Safety for CHERI (arXiv 2605.13210v1)
- Algebraic Semantics of Governed Execution (arXiv 2605.01032v3)