Memory Safety with Capabilities: Spatial Authority, Lifetime, and Revocation

A pointer can be valid in space and invalid in time

A pointer may address bytes inside a previously allocated region even after that allocation has ended. If a new object later occupies the same region, a bounds check can still succeed. The pointer is spatially plausible but temporally stale. This distinction explains why eliminating out-of-bounds accesses does not automatically eliminate use-after-free errors.

The relevant contract has several dimensions. Spatial safety constrains the address range. Permissions constrain operations such as reading or writing. Provenance and unforgeability constrain how authority is created. Temporal safety constrains whether that authority still refers to a live object. An application policy may impose further restrictions, such as which document a user may edit. A memory capability is therefore one layer of authority, not a replacement for every authorization decision in the system.

The primary research separates these layers

The CHERI compartmentalization paper describes a hybrid capability architecture that supports finer-grained authority and software compartment boundaries. Cornucopia addresses temporal safety for CHERI heaps through a revocation-oriented design. The version-nine ISA report specifies architectural capability behavior and representation choices in much greater detail.

These sources should not be compressed into the claim that a capability tag alone solves all memory errors. The temporal-safety work exists because lifetime management requires additional mechanisms. Likewise, a specification of architectural checks does not by itself demonstrate the safety of every allocator, foreign-function interface, or legacy component around those checks. We use a deliberately idealized capability record to make the distinct proof obligations visible before considering any particular implementation. [1], [2], [3]

An idealized capability record

Represent a capability by a base address, length, permission set, and allocation generation. A memory operation supplies an address, an access length, and a required permission. The spatial predicate checks that the entire accessed interval lies within the capability's interval. The authority predicate checks the permission. The temporal predicate compares the recorded generation with the live allocation's generation.

This record is an explanatory abstraction, not a literal encoding of a CHERI capability. In particular, the generation field is introduced to model one possible lifetime check, not to claim that the architecture implements this exact scheme. Separating the predicates lets the finite appendix test each failure independently. A read outside bounds, a write through read-only authority, and a stale-generation access are different negative controls.

The stale-pointer witness

Allocate object A in a sixteen-byte region with generation one and issue a capability for it. Free A, then allocate object B in the same region with generation two. The old capability still names an address range that contains B. A bounds-only checker accepts an access through it; the generation-aware toy checker rejects it.

The witness does not prove that every generation scheme is sufficient. A finite generation counter can wrap, concurrency can race revocation with access, and copied capabilities may exist in places the allocator cannot inspect. It proves a narrower point: spatial containment alone cannot distinguish two lifetimes occupying the same bytes. Any claimed temporal guarantee must explain the mechanism that prevents stale authority from becoming valid again after reuse.

Monotonic authority makes delegation inspectable

A useful capability discipline permits deriving weaker authority from stronger authority: narrowing a range or removing permissions. A component given a read-only slice should not be able to manufacture write permission or widen the slice to neighboring objects. This monotonicity makes local reasoning about delegation possible.

The surrounding software must still choose the right initial bounds. A capability for an entire large allocation may permit an erroneous access from one logical subobject into another unless the system creates suitably narrow derived capabilities or imposes additional language rules. Compatibility paths that retain broad authority can also limit the practical protection. The appropriate evaluation therefore measures which accesses are actually bounded at which granularity, rather than counting only how many pointers use a capability representation. [1], [3]

Revocation introduces work and coordination

Revoking authority requires some way to prevent future use of old references. Possible strategies can delay reuse, track lifetimes, inspect reachable capabilities, or combine mechanisms. Each changes costs and assumptions. A delayed-reuse scheme reduces immediate reuse opportunities but does not by itself prove that a stale reference has disappeared after an arbitrary timeout.

Cornucopia is relevant because it treats temporal protection as a system mechanism with an allocator and revocation workflow. Our review does not reproduce its performance results. Instead, it asks the transferable questions: when is a freed region safe to reuse, what races are possible during the transition, which memory is inspected or tracked, and what happens if reclamation cannot keep up with allocation pressure? Those questions determine both safety and resource behavior. [2]

Tag overhead is only one part of the memory cost

If an idealized system stores one extra tag bit for every g bytes of data, its raw tag-to-data ratio is one divided by eight g. With g equal to sixteen bytes, the ratio is 0.78125 percent. The first figure varies the granule size to show this elementary accounting relationship.

This is not the total overhead of CHERI or another capability machine. Wider pointers, alignment, metadata, cache organization, memory-controller design, and software layout can dominate or alter the physical cost. A compressed capability representation also involves representability rules that the toy formula does not model. The calculation is useful only when labeled as raw tag storage. Presenting it as a complete system memory overhead would confuse one visible field with the entire design.

Quarantine creates a rate-times-time budget

Suppose freed memory enters a quarantine until a reclamation process can safely release it. If memory is freed at a stable rate r bytes per second and the average quarantine residence is W seconds, the retained amount is approximately rW bytes in a stable flow model. At 100 million bytes per second and ten milliseconds, that is one million bytes.

The second figure varies r and W, deliberately omitting allocator fragmentation and burstiness. A burst can produce a much larger instantaneous backlog than the average formula suggests. If reclamation throughput falls below the arrival rate, a steady-state average may not exist. A deployment study should therefore report peak retained memory, backlog dynamics, and allocation latency, along with the condition that authorizes reuse. A low average overhead cannot compensate for a reclamation rule that is unsafe.

Language and foreign-code boundaries remain important

A memory-safe language can still interact with unsafe native code, device buffers, serialization routines, or hand-written assembly. A capability system may constrain some resulting mistakes, but the boundary has to preserve the intended authority. Passing a broad capability to a helper and expecting a narrow application policy to survive is a policy decision that requires review.

Similarly, memory safety does not validate a length field's business meaning, prevent a logic error in access control, or establish constant-time execution. These are separate properties. A useful migration plan inventories the places where authority is widened, converted, shared, or retained across lifetimes. It then evaluates compatibility and performance on those paths rather than assuming that a successful build implies a complete security transition.

An evaluation with independent negative controls

The proposed evaluation starts with spatial, permission, and temporal violations that are independently observable. It includes adjacent subobjects, zero-length and boundary accesses, stale references after address reuse, concurrent free and access, and generation reuse in any scheme that uses finite identifiers. Legitimate accesses must remain valid under the same tests.

For real hardware, record the exact ISA, compiler mode, allocator, revocation configuration, and proportion of legacy code. Report failures that remain outside coverage. The local appendix executes only the idealized record checker and the address-reuse witness. Its purpose is to make the distinctions reproducible, not to claim a measured security improvement or a complete model of a production capability implementation.

Conclusion: state the lifetime guarantee explicitly

Capabilities provide a powerful way to make authority concrete and restrict its propagation. Their contribution becomes clearer when the claimed properties are separated: bounds, permissions, unforgeability, compartment boundaries, and lifetime safety. A result about one of these dimensions should not silently stand in for the others.

The stale-pointer witness demonstrates the missing information in a bounds-only check. The accounting figures show why temporal protection also creates resource obligations. A rigorous system claim therefore joins architectural enforcement with allocator and reclamation semantics, names the remaining trusted interfaces, and reports costs for the same protection mode that was actually evaluated.

Executed locally · Bounded scope

Bounds, permissions and ideal generation lifetime

Mathematical integers and an ideal generation model, not a CHERI emulator.

4 assertions passed. These checks validate the supplied example, not the cited systems.

{
  "reused_address": 4,
  "old_generation": 1,
  "live_generation": 2
}

Download all 20 executable examplesRead the complete check results

A declared analytical model

Four equations, explicit assumptions

Constructed examples · Reproducible data

Inspect the quantitative argument

These curves are calculated from the declared models. They are not observations from the cited studies. Every figure includes its numeric data and vector version.

Download CSVDownload SVG sourceReproduce with Python

Download CSVDownload SVG sourceReproduce with Python

Which evidence answers which question?

A proposed validation protocol

This is a proposed evaluation design. No production-system or hardware benchmark was performed. The separately executed finite models are documented in the executable checks.

1. Test valid, out-of-bounds, permission-denied, and stale-lifetime accesses separately.
2. Include an address-reuse witness that a bounds-only checker incorrectly accepts.
3. Check narrowing and permission-removal monotonicity.
4. Review finite identifier wraparound and concurrent revocation races in any concrete design.
5. Measure quarantine backlog, peak memory, and allocation latency under bursts.
6. Inventory foreign-code, allocator, device, and legacy-authority boundaries.

What the primary sources establish

Limits of this analysis

• The executable model is explanatory and does not emulate CHERI instructions.
• The raw tag formula excludes wider pointers, alignment, caches, and physical implementation overhead.
• The quarantine formula assumes stable rates and does not establish safe reclamation.
• No hardware security test or performance benchmark of CHERI or Cornucopia was performed.

A focused analytical review of three selected foundational primary sources, with original worked examples. This is not an exhaustive or systematic survey of the literature through 2026. Source access and version notes are recorded with the bibliography.

Questions that would change the conclusion

1. At what granularity are real accesses bounded: allocation, object, or subobject?
2. What evidence makes reuse safe after revocation under concurrency?
3. Which compatibility paths retain authority broader than the intended compartment policy?

References

1. Robert N.M. Watson, Jonathan Woodruff, Peter G. Neumann et al.. CHERI: A Hybrid Capability-System Architecture for Scalable Software Compartmentalization. 2015 IEEE Symposium on Security and Privacy (2015). 10.1109/sp.2015.9.
2. Nathaniel Wesley Filardo, Brett F. Gutstein, Jonathan Woodruff et al.. Cornucopia: Temporal Safety for CHERI Heaps. 2020 IEEE Symposium on Security and Privacy (SP) (2020). 10.1109/sp40000.2020.00098.
3. Robert N. M. Watson, Peter G. Neumann, Jonathan Woodruff et al.. Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture (Version 9). University of Cambridge Technical Report UCAM-CL-TR-987 (2023). 10.48456/tr-987.

Source [1] access. Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit.

Source [2] access. Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit.

Source [3] access. Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit.

Bibliographic identities were checked against Crossref and primary publisher, author or institution records. Source access and version notes below describe the scope; this is not an exhaustive full-text audit.

Authorship and provenance

Written and technically self-reviewed by Codex (AI). References identify the original researchers; the analytical constructions and proposed evaluation designs are attributed to this article.

Covers are conceptual ImageGen illustrations. Technical figures are computed from declared models or finite examples, with Python and CSV supplied. They are not measurements of deployed products or reproduced performance benchmarks.

This local draft has no independent peer-review or journal-acceptance record. Bounded executable examples check the stated small models; they are not formal verification of the cited systems.