PoisonCap: Efficient Hierarchical Temporal Safety for CHERI

arXiv:2605.13210 · cs.AR, cs.CR · Submitted 2026-05-13 · Read on arXiv

Listen

Radio episode about this paper

Transcript

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: I'm Nadia, and with me are Elias and Priya, guest researcher.

Elias: Today's paper: "PoisonCap: Efficient Hierarchical Temporal Safety for CHERI".

Nadia: PoisonCap introduces a novel software-hardware co-design that enhances CHERI systems by enforcing strict, hierarchical use-after-free mitigation and initialisation safety without incurring performance or memory overhead.

Elias: First, who's behind it and why it matters.

Paper summary: Nadia: We've touched on the core idea of PoisonCap and its aim to provide scalable temporal safety with strict use-after-free protection and initialisation safety for CHERI systems. To summarize what the paper claims, it introduces a new poison capability format specifically designed to enforce these two properties on CHERI memory.

Elias: Essentially, they are using bounds within these poison capabilities to scale protection across different allocation layers while keeping compatibility with the current software stack. This mechanism allows more privileged layers to manipulate memory poisoned by lower layers.

Priya: From a privacy and measurement angle, I'm interested in how this hierarchical structure manages the state information; does it provide a clearer picture of memory provenance or usage history when dealing with nested allocations?

Nadia: The paper claims they demonstrate that PoisonCap can be used to identify dangling capabilities in place of Cornucopia’s shadow bitmap. This is presented as enabling hierarchical revocation, which reduces memory overhead compared to using a shadow bitmap.

Elias: The mechanism for initialisation safety relies on a "write-before-read policy," where every capability gets the opposite version of its predecessor, and freed memory is poisoned with capabilities of the same version. This links allocation and deallocation states together in a structured way.

Priya: How does this version tracking relate to the actual data we might see during memory operations? Are there specific patterns in these version changes that indicate unsafe access attempts?

Nadia: Use-after-free is prevented by trapping if a pointer capability version matches the poison capability version found in the memory it tries to access. Similarly, uninitialised access is stopped by trapping on a read through a pointer capability version that doesn't match the poison capability version in the memory being accessed.

Elias: That version checking is where the safety enforcement happens at runtime, tying the temporal safety directly into the operational flow of memory operations. It’s a concrete way to enforce those rules on every access attempt.

Priya: So, this isn't just abstract protection; it's a system that actively checks for version mismatches during reads and writes, which is something we can actually measure in terms of system stability.

Nadia: Exactly, Priya. It moves the safety check from being a passive check to an active trapping mechanism when version invariants are violated. This is what they're building on top of the CHERI foundation.

Elias: The paper also details how this works in practice, implementing PoisonCap extensions in both the Cheri-Toooba CPU and the LLVM compiler toolchain. This shows they've thought through the full hardware/software integration required to make it function correctly.

Priya: And I'm also interested in the cache efficiency part; they extend caches to be poison-aware, preferring replacement of poisoned lines to reduce pollution from quarantined memory. Does this mean less system noise when freed memory is handled?

Nadia: It suggests that by folding efficient cache management of freed memory into a single operation on free, the system can auto-zero on reallocation while simultaneously marking freed memory in the caches. This aims to reduce DRAM traffic overhead by an average of one point four nine percent compared to Cornucopia with zeroing in some evaluations.

Elias: That reduction in DRAM traffic is a measurable hardware benefit, and it's important that they quantify that against existing methods. It moves the discussion from just theoretical safety to tangible system efficiency.

Conclusion: Nadia: So, we've gone through the summary of "PoisonCap: Efficient Hierarchical Temporal Safety for CHERI," covering its introduction, how it enforces safety through version tracking and hierarchical bounds, and the hardware optimizations it introduces for cache management.

Elias: And we've also discussed the implications of this work, particularly how the paper shows that PoisonCap can be used to identify dangling capabilities in place of a shadow bitmap while maintaining compatibility with existing software stacks. The efficiency claims regarding performance and memory overhead are quite specific, mentioning minimal overheads in tests on CHERI-Toooba compared to Cornucopia with zeroing.

Priya: What I take away is that this work provides a mechanism to enforce hierarchical strict use-after-free mitigation and initialisation safety by storing poison capabilities into freed memory regions without introducing performance or memory overhead. This is a significant step for temporal safety in complex systems.

Nadia: That’s the core message, Priya; it’s about achieving this hierarchical protection efficiently without the usual performance penalty associated with such strong safety guarantees. It solidifies how we can build on CHERI to support more robust temporal safety models.

Elias: The paper's title, "PoisonCap: Efficient Hierarchical Temporal Safety for CHERI," really encapsulates the balance they're trying to strike between strict safety and system efficiency. It’s a detailed look at how capability structure can be leveraged for complex temporal safety enforcement.

Priya: The implication is that for systems requiring strong temporal guarantees, like operating systems or critical services, there's a viable path to integrating these kinds of layered safety checks directly into the memory management hardware and software interface. This could lead to much more reliable execution environments.

Nadia: Exactly, Priya; it shows that incremental adoption is possible where it's most beneficial, as the paper suggests, because it incurs no baseline overhead for software that doesn't use these features. It’s about targeted improvement rather than a complete overhaul.

Elias: So, the authors have provided a robust co-design that addresses both the functional requirements of temporal safety and the practical concerns of performance and memory usage in CHERI systems. It sets a clear direction for how we might approach these complex problems going forward.

Priya: And I think the real impact is seeing this level of detail in how they handle initialisation safety, showing it works on quadword-granularity initially and points toward future work for always-on fine-grained safety. That roadmap is very helpful for tracking the evolution of this technology.

Yuecheng Wang, Jonathan Woodruff, Alfredo Mazzinghi, Peter Rugg, Alexandre Joannou, Samuel W. Stark, Robert N. M. Watson, Simon W. Moore

University of Cambridge

cs.AR, cs.CR

Submitted: 2026-05-13

Updated: 2026-09-29

Code: https://github.com/sqlite/sqlite

Project page: https://sqlite.org

License: http://creativecommons.org/licenses/by/4.0/

Importance score: 92/100

The gist: PoisonCap introduces a novel software-hardware co-design that enhances CHERI systems by enforcing strict, hierarchical use-after-free mitigation and initialisation safety without incurring

Key concepts

Poison Capabilities
These are new capability types that restrict access to the memory location where they are stored. They include a poison bit and a permission called perm_poison, allowing capabilities to store poison data into memory or update memory versions, which is key for tracking freed regions.
Hierarchical Safety
PoisonCap uses capability bounds metadata to represent the layer at which memory has been freed. This allows the system to determine the highest level of freeing by inspecting 'poison_bounds,' enabling revokers to invalidate capabilities pointing to memory freed at equal or greater levels.
Write-Before-Read Policy
This policy ensures initialisation safety. Every new capability gets a version different from its predecessor, and freed memory is poisoned with capabilities matching the old version. Traps occur if a pointer's capability version matches the poison capability version in the memory being accessed.
Poison-Aware Caches
The system extends caches to be 'poison-aware,' preferring to replace cache lines containing poisoned memory. This reduces cache pollution by quarantining freed memory and folds efficient cache management into a single operation during the free process.

Terminology

Summary

PoisonCap introduces a novel software-hardware co-design that enhances CHERI systems by enforcing strict, hierarchical use-after-free mitigation and initialisation safety without incurring performance or memory overhead.

How it works

PoisonCap is a hardware extension to CHERI called poison capabilities, which are a new capability type designed to prevent access to the memory location where they are stored. These poison capabilities include:

  1. A poison bit indicating that the capability restricts access to its own memory location.

  2. A perm poison permission, allowing a capability to either store poison capabilities into memory, detoxify memory by overwriting them, or update the memory version of a capability.

  3. A special store instruction to poison memory.

  4. A version field used to allow references from new allocations that have been poisoned and preserve the bounds of the allocation that has been poisoned to allow accesses from more powerful allocators.

Hierarchical Safety and Revocation

PoisonCap enables hierarchical use-after-free and uninitialised access protection for nested allocators by using capability bounds metadata. The paper states, Poison capabilities use their bounds to represent the layer at which the memory has been freed. This allows the revoker to determine the greatest level at which memory has been freed simply by inspecting the poison bounds stored in the memory. During a revocation pass, any capability pointing to poison of equal or greater bounds will be invalidated/revoked. This mechanism avoids relying on a shadow bitmap, which is noted as having a non-negligible performance and memory overhead and not scaling well with nested allocators.

Initialisation Safety Enforcement

The paper enforces initialisation safety through a write-before-read policy. Every capability returned on allocation is assigned the opposite version of its predecessor, and freed memory is poisoned with capabilities of the same version as the freed allocation. Use-after-free is prevented by trapping if a pointer capability version matches the poison capability version found in the memory it attempts to access. Uninitialised access is prevented by trapping on a read through a pointer capability version that is different from the version of a poison capability in the memory being accessed.

Performance and Cache Efficiency

PoisonCap aims to enforce these protections without performance and memory overhead. In hardware, it introduces instruction decoding support for poison instructions and poison detection units on both memory load and store. Furthermore, it extends caches to be poison-aware, preferring replacement of poisoned cache lines to reduce pollution of caches with quarantined memory. This allows the system to fold efficient cache management of freed memory into a single operation on free which both marks freed memory in the caches and auto-zeros on reallocation. Evaluations show that PoisonCap does not introduce any additional performance overhead relative to Cornucopia with zeroing and can yield a slight performance improvement by reducing CPU cycle overhead.

Software Compatibility and Evaluation

PoisonCap has been implemented across the entire CHERI software stack, including the LLVM compiler toolchain, CheriBSD operating system, and Jemalloc user-space allocators. The implementation proved out the nestability of PoisonCap using poison bounds, allowing for elegant delegation of poisoning and detox privilege to the MEMSYS5 allocator without disrupting the upstream allocator. Evaluations using the NIST Juliet test suite demonstrated that PoisonCap mitigates all vulnerabilities in the CWE-416 Use After Free class, improving upon Cornucopia’s use-after-reallocation mitigation. For initialisation safety, it successfully detected all vulnerabilities in bad cases with no false positives. The paper concludes that for performance and hardware impact evaluations on CHERI-Toooba, PoisonCap adds only minimal overheads, showing a reduction in DRAM traffic overhead by an average of 1.49% compared to Cornucopia with zeroing.

Conclusion

PoisonCap is a novel software-hardware co-design that improves the CHERI temporal safety security model to support hierarchical strict use-after-free mitigation and initialisation safety by storing poison capabilities into freed memory regions, achieving this without performance and memory overhead. The prototype implementations in QEMU and FPGA demonstrate robust use-after-free memory safety. PoisonCap supports hierarchical use-after-free mitigation as well as initialisation safety without performance and memory overhead. As with other CHERI mechanisms, PoisonCap is software-driven, and incurs no baseline overhead for software that does not use these features, enabling incremental adoption where it is found to be most beneficial. The results from SQLite and SPEC2006 benchmark results indicate very low overhead for the strong protection provided. The prototype implementation in the kernel revoker showed feasibility but requires further correctness evaluation regarding recursive page fault handling. PoisonCap currently supports only quadword-granularity (128-bit) initialisation safety, with future work aimed at improving software and compiler support for always-on fine-grained initialisation safety.

Improvements for AI systems

Based on the provided scientific paper, PoisonCap: Efficient Hierarchical Temporal Safety for CHERI, here are the specific improvements that can be made to AI systems (specifically those running on or interacting with CHERI-enabled hardware) and what those improved systems can do:

  1. ""Enforce Strict Use-After-Free (UAF) Mitigation.""

  2. ""Prevent Information Leakage from Uninitialised Memory Access.""

  3. ""Ensure Deterministic, Hierarchical Safety Across Nested Allocators.""

  4. ""Improve Cache Efficiency by Communicating Memory Liveness to the Microarchitecture.""

Specific improvements and capabilities:

  1. The improved system can guarantee that memory freed via a specific allocation mechanism (like a heap) is immediately inaccessible for use after reallocation, eliminating vulnerabilities like Use-After-Free (UAF) where dangling pointers are exploited between free and reuse.

  2. The improved system will detect and trap any attempt to read uninitialised memory, preventing undefined behavior caused by accessing data that has not been properly set during allocation or initialization.

  3. The system can support complex, layered software stacks (like nested allocators in databases or custom memory pools) by enforcing a hierarchical safety model. This means that if a lower-level allocator frees memory, higher-level allocators automatically inherit the safety guarantee, preventing dangling capabilities from bypassing revocation at any layer of the allocation hierarchy.

  4. The improved system will communicate the liveness (i.e., whether memory is in use or freed) to the hardware cache subsystem via poison capabilities. This allows for intelligent cache management where memory lines marked as poisoned are prioritized for replacement, reducing pollution and improving DRAM bandwidth efficiency, thereby increasing overall system performance.

Abstract

In this paper, we present PoisonCap: scalable temporal safety with strict use-after-free protection and initialisation safety for CHERI systems. Efficient memory safety is an increasing priority for programming languages, operating systems, and hardware designs, and CHERI is a leading hardware/software system that provides native spatial safety and a foundation for temporal memory safety. Cornucopia Reloaded, the current state-of-the-art CHERI temporal safety solution, provides use-after-reallocation safety instead of stronger use-after-free safety, and is not able to enforce initialisation safety. We show that a new 'poison' capability format can be used to enforce strict use-after-free and initialisation safety, and also to communicate memory state to the microarchitecture for efficient cache management of quarantined memory. We enable elegant delegation of memory poisoning privilege using capability bounds to allow nested allocators to enforce safety on their consumers without disturbing upstream allocators. PoisonCap can replace the Cornucopia shadow bitmap, and also automatically zeros memory on reallocation, or optionally traps on read-before-write to enforce initialisation safety. As a result, it incurs no fundamental overhead relative to a Cornucopia baseline that zeros before reallocation, strengthening CHERI temporal safety without performance overhead.

Sources

Related papers