PoisonCap: Efficient Hierarchical Temporal Safety for CHERI

summary

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

In short

PoisonCap is a hardware extension for CHERI systems that enforces strict, hierarchical use-after-free and uninitialised access protection without performance or memory overhead. It introduces 'poison capabilities' to prevent access to freed memory locations, using capability bounds metadata to manage nested allocators safely.

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 used across episodes

Reinforcement Learning (RL) — explained in 24 episodes
Retrieval-Augmented Generation (RAG) — explained in 16 episodes
Interpretability — explained in 15 episodes
Sample Complexity — explained in 15 episodes
Federated Learning — explained in 14 episodes
Generalization — explained in 13 episodes

This episode discusses

The paper

PoisonCap: Efficient Hierarchical Temporal Safety for CHERI · Read on arXiv

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

University of Cambridge

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.

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.

More episodes

← Home