Pith. sign in

REVIEW 4 major objections 5 minor 1 cited by

This paper claims that CHERI can get deterministic heap use-after-free protection by tagging capabilities with a small 'color' that a hardware table can invalidate in bulk, letting freed memory be reused immediately.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-03 03:01 UTC pith:CROOXXDS

load-bearing objection Genuinely new CHERI temporal-safety idea with a real implementation and credible numbers, but the determinism claim hinges on a fence in the free path that the paper never shows; worth serious refereeing. the 4 major comments →

arxiv 2602.09131 v2 pith:CROOXXDS submitted 2026-02-09 cs.CR

PICASSO: Scaling CHERI Use-After-Free Protection to Millions of Allocations using Colored Capabilities

Merve G\"ulmez , Ruben Sturm , Hossam ElAtali , H{\aa}kan Englund , Jonathan Woodruff , N. Asokan , Thomas Nyman This is my paper
classification cs.CR
keywords colored capabilitiesCHERItemporal memory safetyuse-after-freedouble-freecapability revocationprovenance-validity tableheap safety
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper proposes colored capabilities, a CHERI extension that gives each heap allocation a provenance identifier embedded in the capability and tracks that identifier's validity in a hardware table, the provenance-validity table (PVT). When memory is freed, one bit in the table is cleared, which instantly retracts every outstanding capability to that allocation without scanning memory or quarantining the block. The proposal is realized in PICASSO, a CHERI-RISC-V processor and CheriBSD OS stack, and evaluated against the NIST Juliet suite and SPEC/real workloads. If correct, it closes the use-after-free and use-after-reallocation gap deterministically, removes the quarantine delay, and cuts revocation sweeps from per-20-transactions to effectively rare events.

Core claim

The central claim is that CHERI's lack of indirection, not lack of a revocation mechanism, is what makes temporal safety expensive. Colored capabilities add a controlled indirection: a capability carries a provenance identifier (a 'color') in its object-type field, and the hardware maintains a per-process provenance-validity table (PVT) indexed by that identifier. Any load or store through a colored capability checks the one-bit validity entry, and a free() simply clears the bit, so all capabilities with that provenance become undereferenceable at once. The color space is about 2 million identifiers on the prototype, so a full revocation sweep is deferred until the identifier pool nears exha

What carries the argument

The provenance-validity table (PVT) plus the colored capability's embedded provenance identifier. A 1-bit validity entry per identifier says whether capabilities with that color may be dereferenced; hardware checks it on every load and store, a small PVT buffer makes the check near-free by keying on the virtual address of the bit, and a dedicated translation structure handles address translation only on misses. This is what converts per-capability revocation into bulk retraction.

Load-bearing premise

The guarantee collapses if any load can see a stale 'valid' bit for a color whose free() already cleared it; correctness relies on fences accompanying PVT updates, and on an out-of-order core a fence is exactly the costly operation the PVT buffer was designed to avoid.

What would settle it

Instrument the system so that free() clears a PVB and then a subsequent load through the same colored capability completes before any fence is executed; if even one such load succeeds, the freshness premise is violated and the determinism claim fails.

Watch this falsifier — get emailed when new claim-graph text bears on it.

If this is right

  • Freed heap memory can be returned to the allocator immediately, so applications never see quarantine-induced memory bloat or allocation delays.
  • The gap between free and revocation disappears: a dangling pointer to a reused object faults at dereference because its color was invalidated, so use-after-reallocation is blocked as well as use-after-free.
  • Revocation sweeps become rare and non-urgent; they only need to reclaim colors before reuse, so they can run asynchronously in the background.
  • The same free-path check that clears the validity bit detects double-free deterministically, independent of the allocator's behavior.
  • Because the mechanism is architectural, no compiler instrumentation or pointer analysis is needed to catch heap use-after-free bugs.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • If the freshness assumption can be made robust, the design suggests that CHERI's 'no indirection' principle can be relaxed selectively: indirection only for provenance, not for every capability access.
  • A testable extension would be to apply the same PVT mechanism to kernel heap objects or to persistent memory, where sweep frequency is even more costly and quarantine is unacceptable.
  • The 21-bit color space implies that extremely long-running single-process servers will eventually exhaust colors; the paper's own data (one revocation per 66,000 pgbench transactions) suggests this is a policy question about when to sweep, not whether.
  • A possible scale-up is to use pointer-masking bits to widen the identifier space, but the PVT grows linearly, so a dynamically sized PVT would be needed; the paper flags this as future work rather than a claim.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper introduces "colored capabilities," an extension to CHERI that repurposes the capability's otype field as a provenance identifier and adds a hardware-managed provenance-validity table (PVT) with one validity bit per identifier. Loads/stores through colored capabilities check the PVT and fault if the provenance has been invalidated on free, thereby retracting all capabilities to a freed allocation at once. This is claimed to eliminate the quarantine buffer, allow immediate memory reuse, and drastically reduce revocation-sweep frequency. The design is implemented in the CHERI-Toooba out-of-order FPGA softcore and in QEMU, integrated into CheriBSD and LLVM, and evaluated against Juliet CWE-415/416, SPEC CPU2006 INT, SQLite, pgbench, and gRPC.

Significance. If the central guarantee holds, this is a substantial step for CHERI temporal safety: it would give deterministic use-after-free/use-after-reallocation prevention without quarantine, with measured overheads of about 5% on SPEC and lower tail latencies than Cornucopia. The paper ships a real hardware implementation and external-benchmark evidence rather than simulation-only results, and the reduction in revocation frequency is quantified across several workloads. However, the main security claim depends on two unproven architectural assumptions: coherence of the PVT cache with respect to free-path writes, and completeness of the asynchronous revocation sweep before identifier reuse. These are load-bearing for G1 and G3, respectively. The OTYPETH-based coexistence with CHERI sealing is also left underspecified.

major comments (4)
  1. [§6.1–§6.2, Figure 9] The deterministic guarantee stated in §5.2 — that an invalidated provenance identifier makes all corresponding capabilities non-dereferenceable — relies on every subsequent colored load/store observing the cleared PVB. Section 6.1 introduces a PVT buffer and states: "To maintain coherence, all buffer entries are invalidated on fence instructions; correctness relies on fences accompanying page-table updates and writes to the PVT." However, the free() path in §6.2 and Figure 9 invalidates the PVB via an ordinary store (step ❸) and no fence is described on that path. Since the PVT buffer is only invalidated by fences and is checked combinationally before the cache, a stale PVB=1 can remain in the buffer and permit a later dereference of a freed colored capability. On an out-of-order core this is exactly the scenario the buffer creates. This is not a microarchitectural optimization detail; i
  2. [§5.2, §6.2] The paper claims that revocation "does not require capability sweeps to be atomic" because invalidated provenance identifiers already prevent dereference, and that "a revocation pass for a given provenance identifier has to simply complete before that identifier is returned to the pool." The paper does not show how this completeness is guaranteed for capabilities held in live registers or written to memory after the concurrent sweep snapshot. Cornucopia Reloaded needed atomic epochs and register-file scans precisely to avoid this hole. If a stale capability survives in a register or in memory that the sweep has already visited, and then the identifier is re-validated and reused for a new allocation, the stale capability becomes dereferenceable again, reopening UAF/UAR. Figure 10 shows the kernel clearing PVT bits and releasing IDs after revocation, but no mechanism is described that ensu
  3. [§6.1, OTYPETH design] The coexistence of colored and sealed capabilities via the OTYPETH CSR is underspecified. The rule maps every otype below OTYPETH to colored, and every otype above to sealed. To obtain the advertised 2^21 color space, OTYPETH must be at least 2^21. But CHERI software uses small positive otypes for sealing (e.g., compartment IDs and unsealing keys). If OTYPETH is set high, all of those become colored capabilities and sealing breaks; if set low, the color space shrinks and the revocation-frequency claims are weakened. The claim in §5.3 that "other system software not using colored capabilities do not require modification" therefore needs justification. Please describe how OTYPETH is chosen, how existing sealed capabilities are kept above the threshold, and what happens to software that relies on arbitrary otype values.
  4. [§7.1] The Juliet validation demonstrates functional detection of simpler use-after-free patterns, but it does not exercise the cache-coherence timing on which the central guarantee depends. Specifically, the 1,385 bad cases may free and immediately reallocate without stressing the PVT-buffer stale-entry condition, so passing Juliet is not evidence that the free-path fence/ordering question is resolved. Please report the hardware count of PVT-buffer hits and any stress test that deliberately creates a stale PVB in the buffer, or otherwise make the test conditions explicit.
minor comments (5)
  1. [Abstract] The abstract reads "NIST Juliet test cases, , real-world CVEs," with a stray comma, and it claims evaluation against real-world CVEs, but no CVE evaluation appears in the paper. Please correct and either add the CVE evaluation or remove the claim.
  2. [Introduction] The introduction and abstract state ">2800 NIST Juliet test cases," but the evaluation covers 1,385 bad and 1,385 good cases, i.e., 2,770. Please reconcile the number.
  3. [Figure 3] The caption reads "CHERI+Memory Tagging" while the text describes memory versioning. Also, the term "Cornucupia" appears in the Figure 12 label.
  4. [Appendix A] Typo: "guest address tranhlation" should be "translation."
  5. [§7.2, Table 4] The pgbench p99 overhead for Cornucopia is reported as +305% in the text and +305.0% in the table; the gRPC text says "3.7× increase" while Table 7 reports +268.2% at p99. These are consistent with each other, but the narrative would benefit from a uniform percentage/multiple convention.

Circularity Check

0 steps flagged

No circular derivation found: PICASSO's guarantees are design-by-construction, and its security and performance results are measured against external benchmarks; the fence-coherence caveat is a correctness risk, not circularity.

full rationale

The paper's derivation chain is not circular. The central guarantee in §5.2 — 'Once a provenance identifier has been invalidated, the hardware ensures that all capabilities with that provenance identifier cannot be dereferenced' — restates the architectural definition in §6.1 that loads/stores via colored capabilities 'implicitly read the corresponding 1-bit PVT entry ... and fault if the PVB indicates the provenance is invalid.' That is the intended mechanism of the design, not a fitted prediction derived from an input that already contains the output. The paper's independent content is the implementation and the external evaluation: Juliet CWE-416/CWE-415 cases, SPEC CPU2006, SQLite, pgbench, and gRPC are all external benchmarks measured on the shipped design, and the revocation counts (e.g., PICASSO revoking once per 66,000 pgbench transactions vs. once per 20 for Cornucopia) are observed outcomes, not numbers forced by construction. The PVT-buffer geometry (64 words, 4-way) is an engineering optimization evaluated on bzip2, and bzip2 also appears in the SPEC aggregate; this is a mild evaluation-economy caveat, not a circular reduction. The one significant weakness is an omitted proof, not circularity: §6.1 states 'correctness relies on fences accompanying page-table updates and writes to the PVT,' while the MRS free() path in §6.2/Figure 9 invalidates the PVB without explicitly showing a fence, and the PVT buffer caches valid PVBs and is invalidated only on fences. If a stale PVB=1 were observable, the G1 guarantee would fail; Juliet does not exercise that microarchitectural timing. This is a correctness/completeness risk to flag, but it does not make any result equivalent to its input, so the circularity score is 0.

Axiom & Free-Parameter Ledger

3 free parameters · 5 axioms · 3 invented entities

The security and performance claims ride on five premises: the standard CHERI spatial-safety axioms (§3), completeness of the inherited capability sweep before color reuse, fence-based freshness of cached PVBs, complete coverage of access instructions by the PVB check, and the OTYPETH split of the otype space. Three hand-chosen constants — the <1% revocation trigger, the OTYPETH value (undisclosed), and the PVT-buffer geometry — shape the measured behavior. No invented entity has independent external evidence; each is internally specified and internally validated.

free parameters (3)
  • Revocation trigger threshold (provenance-ID low-water mark) = <1% of ~2^21 unclaimed IDs (default)
    §6.2: 'a user-defined threshold, less than 1% by default' triggers caprevoke(); this directly sets sweep frequency and the measured performance profile. Hand-chosen constant.
  • OTYPETH CSR threshold = not stated
    §6.1: splits the otype field into colored (0<otype<OTYPETH) and sealed (otype>=OTYPETH) ranges. Its value constrains the usable color space and sealing compatibility; the paper does not disclose the configured value.
  • PVT buffer geometry = 64 words, 4-way set-associative (~8K cached PVBs)
    §6.1: 'kept small ... only 64 words, 4-way set-associative.' It is the decisive performance optimization (§C: bzip2 1.7x to 1.002x) and appears tuned against bzip2, which is also in the headline SPEC g.m.
axioms (5)
  • domain assumption CHERI spatial safety holds: capabilities cannot be forged or widened; bounds and permissions are monotonically non-increasing; allocator satisfies A1-A3.
    The security argument assumes Adv cannot create counterfeit capabilities and that the allocator maintains correct bounds (§3), inherited from CHERI prior work [28,60].
  • domain assumption A revocation sweep finds every surviving capability with a given provenance ID before that ID is reused.
    §5.2: 'A revocation pass for a given provenance identifier has to simply complete before that identifier is returned to the pool.' Deterministic UAF prevention collapses if a single copy escapes; inherited from Cornucopia, not newly established.
  • ad hoc to paper PVT-buffer coherence: every PVB write and relevant page-table update is accompanied by a fence that invalidates cached PVBs before subsequent colored accesses.
    §6.1: 'correctness relies on fences accompanying page-table updates and writes to the PVT.' The MRS free() path (§6.2, Figure 9) is not shown to execute such a fence; a stale cached PVB=1 would defeat the mechanism.
  • ad hoc to paper All memory accesses that can touch heap data via a colored capability pass through the PVB-checking load/store path.
    §6.1 describes PVB checks for l[bhwd]/s[bhwd]. Atomic memory operations and capability loads/stores (CLC/CSC) via colored capabilities are not discussed, leaving a possible unchecked access path.
  • ad hoc to paper Software does not rely on otype values in the colored range for sealing; OTYPETH cleanly separates colored from sealed capabilities.
    The §6.1 OTYPETH rule repurposes the otype field. The paper does not state the configured OTYPETH value, and pre-existing uses of small otypes for sealing would collide with the colored range.
invented entities (3)
  • Colored capability (provenance ID in otype field + ccsettype instruction) no independent evidence
    purpose: Carries allocation provenance so all copies of a dangling pointer can be retracted together via one PVT bit.
    Fully specified and implemented, so the fault-on-invalid-color behavior is falsifiable by any implementer, but no artifact or third-party implementation exists outside the paper — the evidence is the paper's own FPGA/QEMU builds.
  • Provenance-validity table (PVT) with 1-bit PVBs no independent evidence
    purpose: Hardware-managed table indexed by provenance ID; one bit per color gates all colored loads/stores and enables bulk retraction.
    Specified precisely (PVTR, PTLB, PVT buffer) and shown in two implementations, but no external validation of the claimed security guarantees exists outside the paper.
  • OTYPETH CSR no independent evidence
    purpose: Runtime switch deciding whether an otype value means unsealed, colored, or sealed, to keep colored capabilities compatible with CHERI sealing.
    Implementation-defined register; its threshold value is not disclosed and its correctness rests on software never mixing the two ranges.

pith-pipeline@v1.3.0-alltime-deepseek · 26784 in / 27268 out tokens · 250785 ms · 2026-08-03T03:01:58.728468+00:00 · methodology

0 comments
read the original abstract

While the CHERI instruction-set architecture extensions for capabilities enable strong spatial memory safety, CHERI lacks built-in temporal safety, particularly for heap allocations. Prior attempts to augment CHERI with temporal safety fall short in terms of scalability, memory overhead, and incomplete security guarantees due to periodical sweeps of the system's memory to individually revoke stale capabilities. We address these limitations by introducing colored capabilities that add a controlled form of indirection to CHERI's capability model. This enables provenance tracking of capabilities to their respective allocations via a hardware-managed provenance-validity table, allowing bulk retraction of dangling pointers without needing to quarantine freed memory. Colored capabilities significantly reduce the frequency of capability revocation sweeps while improving security. We realize colored capabilities in PICASSO, an extension of the CHERI-RISC-V architecture on a speculative out-of-order FPGA softcore (CHERI-Toooba). We also integrate colored-capability support into the CheriBSD OS and CHERI-enabled Clang/LLVM toolchain. Our evaluation shows effective mitigation of use-after-free and double-free bugs across all heap-based temporal memory-safety vulnerabilities in NIST Juliet test cases, , real-world CVEs, only a small performance overhead on SPEC CPU benchmarks (5% g.m.), less latency, and more consistent performance in long-running SQLite, PostgreSQL, and gRPC workloads compared to prior work.

Figures

Figures reproduced from arXiv: 2602.09131 by H{\aa}kan Englund, Hossam ElAtali, Jonathan Woodruff, Merve G\"ulmez, N. Asokan, Ruben Sturm, Thomas Nyman.

Figure 1
Figure 1. Figure 1: In-memory representation of CHERI capabilities [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Memory allocation lifecycle in Cornucopia. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 4
Figure 4. Figure 4: Colored capabilities allocation lifecycle. [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Colored capabilities overview and free() through enhanced versions of these memory manage￾ment APIs ❶, ❷ integrated via the malloc revocation shim (MRS, §2.3). For brevity, we refer in [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: PICASSO hardware architecture. 6 Implementation In this section, we present Provenance Indirection-enabled CHERI Architecture for Scarcely Swept Objects (PICASSO), our implemen￾tation of colored capabilities for the CHERI-RISC-V architecture. We implemented two versions of PICASSO: 1) a QEMU-system￾CHERI128 full-system emulator, and 2) a softcore based on the CHERI-Toooba processor intellectual property (I… view at source ↗
Figure 7
Figure 7. Figure 7: PVT initialization at process creation. Supporting millions of allocations. In CHERI’s 128-bit capability representation 18 bits are reserved for the otype which we reuse for provenance identifiers, allowing for 2 18 distinct allocation prove￾nances to be tracked. In our current design, applications benefit from a much larger provenance identifier space, which extends the period between needed invocations … view at source ↗
Figure 9
Figure 9. Figure 9: shows our approach to invalidate provenance identifiers when memory is freed. When a free() call is made, it invokes MRS ❶, similar to malloc() calls. Unlike Cornucopia, we do not quarantine the memory. Instead, we read the provenance identifier from the capability ❷ and invalidate the corresponding PVB in the PVT ❸. Prior to invalidation, the MRS checks whether the PVB is already invalidated. This allows … view at source ↗
Figure 10
Figure 10. Figure 10: Colored capability revocation. identifiers for reuse in the unr [PITH_FULL_IMAGE:figures/full_fig_p008_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: SPEC CPU 2006 performance overhead for PICASSO (1.05× g.m.) and Cornucopia (1.11× g.m. in single-core, and 1.08× g.m. in 2-core configuration), and memory overhead of PICASSO (1.08× g.m.) and Cornucopia (1.34× g.m.). size, PICASSO’s memory usage increases during revocation due to handling two PVT tables and the memory consumed by the unr allo￾cator (§6.2). We observe a worst-case memory overhead in PICASS… view at source ↗
Figure 12
Figure 12. Figure 12: Normalized Performance overhead of PICASSO (1.08× avg., 1.12× max.) and Cornucopia (1.12× avg., 1.62× max.) across SQLite speedtest1 operational phases. Phase description and raw data are available in [PITH_FULL_IMAGE:figures/full_fig_p011_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Latency for 200 sample pgbench transactions. Mark￾ers denote individual response times. Initial latency spike at t 1 is due to connection establishment. responses, while measuring throughput and latency percentiles. Each run lasts 120 seconds with an initial 15-second warmup, and each configuration is executed twice with 0-byte request sizes [PITH_FULL_IMAGE:figures/full_fig_p011_13.png] view at source ↗
Figure 15
Figure 15. Figure 15: SPEC CPU 2006 bzip performance overhead for [PITH_FULL_IMAGE:figures/full_fig_p016_15.png] view at source ↗
Figure 17
Figure 17. Figure 17: Approximation of DRAM traffic overhead compare to baseline [PITH_FULL_IMAGE:figures/full_fig_p016_17.png] view at source ↗
Figure 18
Figure 18. Figure 18: Normalized cycles, instructions, and memory overhead for SQLite speedtest1 for Cornucopia and Cornucopia-RoF and PI￾CASSO [PITH_FULL_IMAGE:figures/full_fig_p017_18.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. PoisonCap: Efficient Hierarchical Temporal Safety for CHERI

    cs.AR 2026-05 unverdicted novelty 6.0

    PoisonCap uses a new poison capability format to deliver strict use-after-free and initialization safety for CHERI systems with no fundamental overhead over Cornucopia baselines.

Reference graph

Works this paper leans on

62 extracted references · 3 canonical work pages · cited by 1 Pith paper

  1. [1]

    [n. d.]. SPEC CPU 2006. https://www.spec.org/cpu2006/

    2006

  2. [2]

    [n. d.]. SQLite Home Page. https://sqlite.org/

  3. [3]

    John Hennessy and David Patterson 2017 ACM A.M

    2018. John Hennessy and David Patterson 2017 ACM A.M. Turing Award Lecture. https://www.youtube.com/watch?v=3LVeEjsn8Ts

    2018

  4. [4]

    CTSRD-CHERI/Postgres

    2023. CTSRD-CHERI/Postgres. Capability Hardware Enhanced RISC Instruc- tions. https://github.com/CTSRD-CHERI/postgres

    2023

  5. [5]

    Junho Ahn, and others. 2024. BUDAlloc: Defeating Use-after-Free Bugs by Decoupling Virtual Address Management from Kernel. InUSENIX Security ’24. USENIX, 181–197. https://www.usenix.org/conference/usenixsecurity24/ presentation/ahn

    2024

  6. [7]

    Thomas Aird, and others. 2025. "Svucrg" Extension, Version 1.0 for RV64Y (Stable State). https://riscv.github.io/riscv-cheri/#section_cheri_priv_crg_ext

    2025

  7. [8]

    Thomas Aird, and others. 2025. "Svy" Extension, Version 1.0 for RV64Y (Stable State). https://riscv.github.io/riscv-cheri/#section_priv_cheri_vmem 13

    2025

  8. [9]

    Periklis Akritidis. 2010. Cling: A Memory Allocator to Mitigate Dangling Pointers. InUSENIX Security ’10. USENIX, 12. https://www.usenix.org/conference/ usenixsecurity10/cling-memory-allocator-mitigate-dangling-pointers

    2010

  9. [10]

    2023.CHERIoT: Rethinking Security for Low-Cost Embedded Systems

    Saar Amar, and others. 2023.CHERIoT: Rethinking Security for Low-Cost Embedded Systems. Technical Report MSR-TR-2023-6. Mi- crosoft. https://www.microsoft.com/en-us/research/wp-content/uploads/2023/02/ cheriot-63e11a4f1e629.pdf

    2023

  10. [11]

    Saar Amar, and others. 2023. CHERIoT: Complete Memory Safety for Embedded Devices. InMICRO ’23. ACM, 641–653. doi:10.1145/3613424.3614266

    arXiv 2023

  11. [12]

    Berger and Benjamin G

    Emery D. Berger and Benjamin G. Zorn. 2006. DieHard: Probabilistic Memory Safety for Unsafe Languages. InPLDI ’06. ACM, 158–168. doi:10.1145/1133981. 1134000

    doi:10.1145/1133981 2006

  12. [13]

    Tim Boland and Paul E. Black. 2012. Juliet 1.1 C/C++and Java Test Suite. Computer45, 10 (Oct. 2012), 88–90. doi:10.1109/MC.2012.345

    doi:10.1109/mc.2012.345 2012

  13. [14]

    Jacob Bramley, and others. 2023. Picking a CHERI Allocator: Security and Per- formance Considerations. InISMM 2023. ACM, 111–123. doi:10.1145/3591195. 3595278

    work page doi:10.1145/3591195 2023

  14. [15]

    Juan Caballero, and others. 2012. Undangle: Early Detection of Dangling Pointers in Use-after-Free and Double-Free Vulnerabilities. InISSTA ’12. ACM, 133–143. doi:10.1145/2338965.2336769

    arXiv 2012

  15. [16]

    Paolo Carlini, and others. 2025. The Bitmap_allocator. https://gcc.gnu.org/ onlinedocs/gcc-15.2.0/libstdc++/manual/manual/bitmap_allocator.html

    2025

  16. [17]

    David Chisnall, and others. 2017. CHERI JNI: Sinking the Java Security Model into the C. InASPLOS ’17. ACM, 569–583. doi:10.1145/3037697.3037725

    arXiv 2017

  17. [19]

    Jim Chow, and others. 2005. Shredding Your Garbage: Reducing Data Lifetime Through Secure Deallocation. InUSENIX Security ’15. USENIX. https://www.usenix.org/conference/14th-usenix-security-symposium/ shredding-your-garbage-reducing-data-lifetime-through

    2005

  18. [20]

    Thurston H. Y . Dang, Petros Maniatis, and David Wagner. 2017. Oscar: A Practical Page-Permissions-Based Scheme for Thwarting Dangling Pointers. In USENIX Security ’17. USENIX, 815–832. https://www.usenix.org/conference/ usenixsecurity17/technical-sessions/presentation/dang

    2017

  19. [21]

    Dennis and Earl C

    Jack B. Dennis and Earl C. Van Horn. 1966. Programming Semantics for Mul- tiprogrammed Computations.Commun. ACM9, 3 (March 1966), 143–155. doi:10.1145/365230.365252

    arXiv 1966

  20. [22]

    Duck and Roland H

    Gregory J. Duck and Roland H. C. Yap. 2018. EffectiveSan: Type and Memory Error Detection Using Dynamically Typed C/C++. InPLDI ’18. ACM, 181–195. doi:10.1145/3192366.3192388

    arXiv 2018

  21. [23]

    EEMBC. 2024. Eembc/Coremark. Embedded Microprocessor Benchmark Con- sortium. https://github.com/eembc/coremark

    2024

  22. [24]

    Hossam ElAtali, and others. 2025. BLACKOUT: Data-Oblivious Computation with Blinded Capabilities. InCCS ’25. ACM, 2039–2053. doi:10.1145/3719027. 3765169

    doi:10.1145/3719027 2025

  23. [25]

    Clean Sweep

    Márton Erd˝os, Sam Ainsworth, and Timothy M. Jones. 2022. MineSweeper: A “Clean Sweep” for Drop-in Use-after-Free Prevention. InASPLOS ’22. ACM, 212–225. doi:10.1145/3503222.3507712

    arXiv 2022

  24. [26]

    Reza Mirzazade Farkhani, Mansour Ahmadi, and Long Lu. 2021. PTAuth: Tem- poral Memory Safety via Robust Points-to Authentication. InUSENIX Security ’21. USENIX, 1037–1054. https://www.usenix.org/conference/usenixsecurity21/ presentation/mirzazade

    2021

  25. [27]

    Nathaniel Filardo. 2024. For Discussion: MSR’s CHERI+MTE Composition. https://github.com/riscv/riscv-cheri/issues/340

    2024

  26. [28]

    Nathaniel Wesley Filardo, and others. 2024. Cornucopia Reloaded: Load Barriers for CHERI Heap Temporal Safety. InASPLOS ’24. ACM, 251–268. doi:10.1145/ 3620665.3640416

    arXiv 2024

  27. [29]

    Fuchs, and others

    Franz A. Fuchs, and others. 2024. Safe Speculation for CHERI. InICCD ’24. IEEE, 364–372. doi:10.1109/ICCD63220.2024.00063

    arXiv 2024

  28. [30]

    Franz A Fuchs, and others. 2023. Architectural Contracts for Safe Speculation. doi:10.1109/ICCD58817.2023.00093

    arXiv 2023

  29. [31]

    Aïna Linn Georges, and others. 2021. Efficient and Provable Local Capability Revocation Using Uninitialized Capabilities. InPOPL ’21. 6:1–6:30. doi:10.1145/ 3434287

    2021

  30. [32]

    Richard Grisenthwaite. 2022. Arm Morello Evaluation Platform -Validating CHERI-based Security in a High-performance System. InHCS ’22. IEEE, 1–22. doi:10.1109/HCS55958.2022.9895591

    arXiv 2022

  31. [33]

    PostgreSQL Global Development Group. 2026. PostgreSQL. https://www. postgresql.org/

    2026

  32. [34]

    Merve Gülmez, and others. 2025. Mon CHÉRI: Mitigating Uninitialized Memory Access with Conditional Capabilities. InS&P ’15. IEEE, 829–847. doi:10.1109/ SP61157.2025.00133

    arXiv 2025

  33. [35]

    2020.Security Analysis of CHERI ISA

    Nicolas Joly, Saif ElSherei, and Saar Amar. 2020.Security Analysis of CHERI ISA. Technical Report. Microsoft Security Response Center. 42 pages. https: //msrc.microsoft.com/blog/2020/10/security-analysis-of-cheri-isa/

    2020

  34. [37]

    Henry M. Levy. 1984.Capability-Based Computer Systems. Butterworth- Heinemann. https://homes.cs.washington.edu/~levy/capabook/

    1984

  35. [38]

    Yuan Li, and others. 2022. PACMem: Enforcing Spatial and Temporal Memory Safety via ARM Pointer Authentication. InCCS ’22. ACM, 1901–1915. doi:10. 1145/3548606.3560598

    arXiv 2022

  36. [39]

    Beichen Liu, Pierre Olivier, and Binoy Ravindran. 2019. SlimGuard: A Secure and Memory-Efficient Heap Allocator. InMiddleware ’19. ACM, 1–13. doi:10. 1145/3361525.3361532

    arXiv 2019

  37. [40]

    Daiping Liu, Mingwei Zhang, and Haining Wang. 2018. A Robust and Efficient Defense against Use-after-Free Exploits via Concurrent Pointer Sweeping. InCCS ’18. ACM, 1635–1648. doi:10.1145/3243734.3243826

    arXiv 2018

  38. [41]

    Alyssa Milburn, Herbert Bos, and Cristiano Giuffrida. 2017. SafeInit: Compre- hensive and Practical Mitigation of Uninitialized Read Vulnerabilities. Internet Society. doi:10.14722/ndss.2017.23183

    arXiv 2017

  39. [42]

    MITRE. 2024. CWE-562: Return of Stack Variable Address (4.17). https: //cwe.mitre.org/data/definitions/562.html

    2024

  40. [43]

    Santosh Nagarakatte, and others. 2010. CETS: Compiler Enforced Temporal Safety for C.SIGPLAN Not.45, 8 (June 2010), 31–40. doi:10.1145/1837855. 1806657

    work page doi:10.1145/1837855 2010

  41. [44]

    Gene Novark and Emery D. Berger. 2010. DieHarder: Securing the Heap. InCCS ’10. ACM, 573–584. doi:10.1145/1866307.1866371

    arXiv 2010

  42. [45]

    Chanyoung Park and Hyungon Moon. 2024. Efficient Use-After-Free Prevention with Opportunistic Page-Level Sweeping. InNDSS 2024. Internet Society. doi:10. 14722/ndss.2024.24804

    arXiv 2024

  43. [46]

    David D. Redell. 1974.Naming and Protection in Extendible Operating Systems. Technical Report MAC TR-140. Massachussets Institute of Technology. 169 pages. https://apps.dtic.mil/sti/tr/pdf/ADA001721.pdf

    1974

  44. [47]

    2023.Efficient spatial and temporal safety for microcon- trollers and application-class processors

    Peter David Rugg. 2023.Efficient spatial and temporal safety for microcon- trollers and application-class processors. Technical Report UCAM-CL-TR-984. University of Cambridge, Computer Laboratory. doi:10.48456/tr-984

    work page doi:10.48456/tr-984 2023

  45. [48]

    Jerome H. Saltzer. 1974. Protection and the Control of Information Sharing in Multics.Commun. ACM17, 7 (July 1974), 388–402. doi:10.1145/361011.361067

    arXiv 1974

  46. [49]

    2017.Pointer Authentication on ARMv8.3: Design and Analysis of the New Software Security Instructions

    Qualcomm Product Security. 2017.Pointer Authentication on ARMv8.3: Design and Analysis of the New Software Security Instructions. Whitepaper. Qualcomm Technologies, Inc. 12 pages. https://www.qualcomm.com/content/dam/qcomm- martech/dm-assets/documents/pointer-auth-v7.pdf

    2017

  47. [50]

    Ved Shanbhogue. 2024. "B" Extension for Bit Manipulation, Version 1.0.0 :: RISC- V Ratified Specifications Library. https://docs.riscv.org/reference/isa/unpriv/b-st- ext.html

    2024

  48. [51]

    Sam Silvestro, and others. 2017. FreeGuard: A Faster Secure Heap Allocator. In CCS ’17. ACM, 2389–2403. doi:10.1145/3133956.3133957

    arXiv 2017

  49. [52]

    Sam Silvestro, and others. 2018. Guarder: A Tunable Secure Allocator. In USENIX Security ’18. USENIX, 117–133. https://www.usenix.org/conference/ usenixsecurity18/presentation/silvestro

    2018

  50. [53]

    GCC Team. 2025. Options to Request or Suppress Warnings: -Wno-return-local- addr. https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Warning-Options.html# index-Wno-return-local-addr

    2025

  51. [54]

    LLVM Team. 2025. Diagnostic Flags in Clang — Clang 22.0.0git Documen- tation. https://releases.llvm.org/20.1.0/tools/clang/docs/DiagnosticsReference. html#wreturn-stack-address

    2025

  52. [55]

    LLVM Team. 2025. Scudo Hardened Allocator. https://releases.llvm.org/20.1.0/ docs/ScudoHardenedAllocator.html

    2025

  53. [56]

    Craig Tiller, and others. 2025. gRPC. https://github.com/grpc/grpc/tree/v1.54.2

    2025

  54. [57]

    Erik van der Kouwe, Vinod Nigade, and Cristiano Giuffrida. 2017. DangSan: Scalable Use-after-free Detection. InEuroSys ’17. ACM, 405–419. doi:10.1145/ 3064176.3064211

    arXiv 2017

  55. [58]

    2019.An Introduction to CHERI

    Robert N M Watson, and others. 2019.An Introduction to CHERI. Technical Report UCAM-CL-TR-941. Computer Laboratory, University of Cambridge. 43 pages pages. https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-941.pdf

    2019

  56. [59]

    Robert N. M. Watson, and others. 2023.Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture (Version 9). Technical Report UCAM-CL-TR-987. Computer Laboratory, University of Cambridge. 523 pages pages. doi:10.48456/TR-987

    doi:10.48456/tr-987 2023

  57. [60]

    Nathaniel Wesley Filardo, and others. 2020. Cornucopia: Temporal Safety for CHERI Heaps. InS&P ’20. IEEE, 608–625. doi:10.1109/SP40000.2020.00098

    arXiv 2020

  58. [61]

    Brian Wickman, and others. 2021. Preventing Use-After-Free Attacks with Fast Forward Allocation. InUSENIX Security Symposium ’21. USENIX, 2453–2470. https://www.usenix.org/conference/usenixsecurity21/presentation/wickman

    2021

  59. [62]

    Matthew Wilcox. 2025. ID Allocation. https://www.kernel.org/doc/html/v6.18/ core-api/idr.html#id-allocation

    2025

  60. [63]

    Jonathan Woodruff, and others. 2019. CHERI Concentrate: Practical Compressed Capabilities.IEEE Trans. Comput.68, 10 (Oct. 2019), 1455–1469. doi:10.1109/ TC.2019.2914037

    arXiv 2019

  61. [64]

    Yves Younan. 2015. FreeSentry: Protecting Against Use-After-Free Vulnerabilities Due to Dangling Pointers. InNDSS ’15. Internet Society. doi:10.14722/ndss.2015. 14 23190

    doi:10.14722/ndss.2015 2015

  62. [65]

    claimed”, len=50}. To save memory, multiple small runs can be combined into one bitmap representation of a fixed size (in our case 512 bits), for example: {state=“claimed

    Adam Zabrocki, and others. 2024. RISC-V Pointer Masking, Version 1.0 (Ratified). https://raw.githubusercontent.com/riscv/riscv-j-extension/master/zjpm-spec.pdf A QEMU Implementation We implemented a functional model of PICASSO in QEMU-system- CHERI128 to enable kernel development and functional validation prior to hardware development. The QEMU implementa...

    2024