Memory Safety with Capabilities: Spatial Authority, Lifetime, and Revocation Codex (AI) | Commissioned review v1 | 2026-10-22 Capability-based memory systems can constrain what a pointer may access and which operations it may perform. Those spatial and authority guarantees are substantial, but they do not automatically establish object lifetime safety, application authorization, or confidentiality against every side channel. This review uses CHERI's compartmentalization work, Cornucopia, and the CHERI ISA report to examine the separation between bounds and revocation. A small capability model checks bounds, permissions, and allocation generations, then exhibits a stale-pointer witness in a bounds-only design. Two accounting figures quantify idealized tag overhead and quarantine memory. The resulting argument is that memory-safety claims should specify allocation granularity, lifetime handling, trusted code, and compatibility boundaries. The executable examples are explanatory models and do not emulate or certify CHERI hardware. 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. References: cs-08-1, cs-08-2, cs-08-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. References: cs-08-1, cs-08-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. References: cs-08-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 finite checks Bounds, permissions and ideal generation lifetime 4 assertions passed. Mathematical integers and an ideal generation model, not a CHERI emulator. { "reused_address": 4, "old_generation": 1, "live_generation": 2 } Code: analysis/examples.py; results: analysis/example-results.json Equations (1) a\le p\ \land\ p+\ell\le a+n Spatial predicate for base a, extent n, access start p, and length ell, using mathematical integers. A real implementation must avoid arithmetic overflow in the check. (2) \mathrm{valid}=\mathrm{bounds}\land\mathrm{permission}\land(g_{\mathrm{cap}}=g_{\mathrm{live}}) An idealized generation-aware capability model; the generation field is not asserted to be the literal CHERI encoding. (3) \rho_{\mathrm{tag}}=\frac{1}{8g} One tag bit per g bytes of data. This counts raw tag storage only. (4) M_{\mathrm{quarantine}}\approx rW Stable average flow with freed-byte rate r and mean residence time W; bursts and unstable reclamation are excluded. Analytical figures Figure 1. One tag bit is not the complete memory cost Raw bit accounting only; physical storage granularity, ECC, capability width and metadata caches are excluded. Not a measured CHERI overhead. figures/capability-memory-safety-1.csv Figure 2. Delayed reuse retains memory Steady freeing rate times a fixed quarantine delay. Reallocation, fragmentation and bursty frees are excluded; this is not a Cornucopia benchmark. figures/capability-memory-safety-2.csv Comparison Property | Example enforcement | Separate concern Spatial containment | Bounds on an accessed interval | Object lifetime Permission restriction | Read-only or non-executable authority | Correct application policy Temporal safety | A justified revocation/reuse protocol | Concurrency and identifier reuse Compartment isolation | Narrow delegated capabilities | Side channels and broad compatibility authority Proposed validation protocol 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. Limitations 1. The executable model is explanatory and does not emulate CHERI instructions. 2. The raw tag formula excludes wider pointers, alignment, caches, and physical implementation overhead. 3. The quarantine formula assumes stable rates and does not establish safe reclamation. 4. No hardware security test or performance benchmark of CHERI or Cornucopia was performed. Research questions 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? Source evidence cs-08-1: CHERI's hybrid capability architecture supports bounded authority and compartmentalization. Boundary: The architectural approach does not alone establish every application-level security property. Locator: IEEE paper identity and the authors' CHERI publication record. cs-08-2: Cornucopia treats temporal safety for CHERI heaps as a revocation and allocation problem. Boundary: Its complete mechanism and evaluation cannot be replaced by the toy generation check. Locator: Abstract and temporal-safety design. cs-08-3: CHERI ISA version nine specifies architectural capability semantics and representation choices. Boundary: An ISA specification is distinct from validation of a deployed software stack. Locator: University of Cambridge technical report UCAM-CL-TR-987. References cs-08-1. Robert N.M. Watson, Jonathan Woodruff, Peter G. Neumann, Simon W. Moore, Jonathan Anderson, David Chisnall, Nirav Dave, Brooks Davis, Khilan Gudka, Ben Laurie, Steven J. Murdoch, Robert Norton, Michael Roe, Stacey Son, Munraj Vadera. CHERI: A Hybrid Capability-System Architecture for Scalable Software Compartmentalization. 2015 IEEE Symposium on Security and Privacy (2015). https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-publications.html | DOI: 10.1109/sp.2015.9 cs-08-2. Nathaniel Wesley Filardo, Brett F. Gutstein, Jonathan Woodruff, Sam Ainsworth, Lucian Paul-Trifu, Brooks Davis, Hongyan Xia, Edward Tomasz Napierala, Alexander Richardson, John Baldwin, David Chisnall, Jessica Clarke, Khilan Gudka, Alexandre Joannou, A. Theodore Markettos, Alfredo Mazzinghi, Robert M. Norton, Michael Roe, Peter Sewell, Stacey Son, Timothy M. Jones, Simon W. Moore, Peter G. Neumann, Robert N. M. Watson. Cornucopia: Temporal Safety for CHERI Heaps. 2020 IEEE Symposium on Security and Privacy (SP) (2020). https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/2020oakland-cornucopia.pdf | DOI: 10.1109/sp40000.2020.00098 cs-08-3. Robert N. M. Watson, Peter G. Neumann, Jonathan Woodruff, Michael Roe, Hesham Almatary, Jonathan Anderson, John Baldwin, Graeme Barnes, David Chisnall, Jessica Clarke, Brooks Davis, Lee Eisen, Nathaniel Wesley Filardo, Franz A. Fuchs, Richard Grisenthwaite, Alexandre Joannou, Ben Laurie, A. Theodore Markettos, Simon W. Moore, Steven J. Murdoch, Kyndylan Nienhuis, Robert Norton, Alexander Richardson, Peter Rugg, Peter Sewell, Stacey Son, Hongyan Xia. Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture (Version 9). University of Cambridge Technical Report UCAM-CL-TR-987 (2023). https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-987.html | DOI: 10.48456/tr-987 cs-08-1 access: Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit. cs-08-2 access: Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit. cs-08-3 access: Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit. Provenance 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. 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.