hardware-Enforced Memory Safety: ARM MTE and cheri
Overview
hardware-enforced memory safety replaces probabilistic software filters with deterministic hardware primitives to bind sensitive data to specific execution rights. Current software-based countermeasures often induce significant runtime overhead and fail to prevent memory-related vulnerabilities [C000]. This shift moves the security boundary from the application layer to the Instruction Set Architecture (ISA), utilizing ARM MTE or CHERI to ensure that untrusted data cannot be interpreted as authorized commands.
This transition is critical because software-level isolation cannot inherently prevent the modification or leakage of security-critical data [C000]. While ARM MTE provides a pragmatic approach via memory tagging to mitigate common exploits [C005], it remains probabilistic due to high tag collision probabilities [C000]. In contrast, CHERI implements a hybrid capability model that provides byte-granularity memory protection [C002], rendering pointers unforgeable and enforcing strict hardware bounds on memory access [C004].
Despite these hardware primitives, a "semantic gap" exists; the ISA does not automatically understand a language's object model [C008]. Ensuring that hardware-enforced safety actually prevents leakage requires the precise mapping of pointer provenance and memory object semantics onto the hardware capabilities [C008]. Furthermore, while spatial safety is effectively handled by capabilities [C004], temporal safety—specifically Use-After-Free vulnerabilities—requires the integration of asynchronous revocation services like Cornucopia to track and invalidate capability flow through memory [C009].
Landscape
Current implementations for hardware-enforced memory safety and capability-based isolation split into two primary architectural paths: probabilistic tagging and deterministic capability models.
Probabilistic Mitigation: ARM MTE
ARM MTE (Memory Tagging Extension) implements memory safety by assigning small meta-information tags to memory objects [C000]. This approach is designed for low-friction deployment as a runtime exploit mitigation tool [C005]. However, because tag sizes are small, the protection is probabilistic; high tag collision probabilities limit its ability to provide absolute security guarantees [C000]. Performance varies significantly by microarchitecture, with some benchmarks showing modest overhead while others experience slowdowns up to 6.64x [C006].
Deterministic Prevention: cheri
The CHERI (Capability hardware Enhanced RISC Instructions) model extends the ISA to provide byte-granularity memory protection [C002]. Unlike MTE, cheri uses hardware capabilities as the sole protection mechanism to enforce language memory models and fault isolation in hardware [C001, C002].
Key implementations include:
* CheriBSD: A port of the FreeBSD operating system that utilizes an extended LLVM compiler to implement cheri memory protection [C002, C007].
* CheriRTOS: A capability model specifically for embedded devices (automotive, medical, robotics) providing scalable task isolation and real-time guarantees [C001].
* Cornucopia: A revocation system that addresses the "temporal safety" gap in cheri. While cheri natively prevents out-of-bounds spatial violations [C004], Cornucopia implements non-probabilistic temporal safety for heap allocations via a concurrent kernel-resident revocation service [C009].
Comparison of hardware Substrates
| Feature | ARM MTE | cheri |
|---|---|---|
| Safety Guarantee | Probabilistic (Tag collisions possible) [C000] | Deterministic (hardware-enforced bounds) [C002] |
| Primary Strength | Low-friction deployment/telemetry [C005] | Fine-grained spatial safety & isolation [C001, C007] |
| Implementation | Tagged memory extensions [C000] | ISA overhaul / Hybrid capability model [C002, C003] |
| temporal Safety | Limited/Probabilistic [C000] | Requires external revocation (e.g., Cornucopia) [C009] |
| Performance | Variable; up to 6.64x slowdown [C006] | Performance-competitive with RISC [C002] |
By moving from software-based filtering to a substrate where execution rights are bound to hardware tags, systems can eliminate the gap between the intended security policy and the actual memory access, rendering unauthenticated remote code execution (RCE) physically impossible at the ISA level [C001, C007].
Key Findings
Evidence indicates a fundamental divide between probabilistic mitigation and deterministic prevention in memory safety. ARM MTE utilizes memory tagging to assign meta-information to objects, but the small size of these tags results in high collision probabilities, limiting the strength of its protection guarantees [C000]. In contrast, CHERI implements a hybrid capability model that provides byte-granularity memory protection and unforgeable pointers, moving enforcement from software into the hardware ISA [C002, C003].
While spatial safety—the prevention of out-of-bounds access—is effectively solved by capability-based addressing [C004], temporal safety (Use-After-Free) remains a critical vulnerability. Deterministic temporal safety requires active capability revocation. Cornucopia addresses this by implementing a concurrent kernel-resident revocation service that tracks capability flow through memory, demonstrating an average overhead of less than 2% and a worst-case of 8.9% on SPEC CPU2006 benchmarks [C009].
A critical "Semantic Gap" exists between hardware primitives and high-level language models. hardware capabilities cannot inherently recognize a language's object model. Consequently, security depends on the precise mapping of pointer provenance—the link between a pointer and its allocated memory object—onto hardware capabilities [C008]. Without this mapping, the system remains vulnerable to provenance violations that the hardware cannot detect.
Implementation data confirms that capability-based models are viable even in resource-constrained environments. CheriRTOS demonstrates that hardware capabilities can serve as the sole protection mechanism for embedded systems, providing scalable task isolation and fine-grained memory safety without violating strict embedded resource constraints [C001].
Tensions and Tradeoffs
Practitioners implementing hardware-enforced safety must navigate the conflict between deterministic security guarantees and the friction of deployment. The primary tension lies in the choice between probabilistic mitigation and hard hardware boundaries.
While ARM MTE offers a low-friction path for in-process access control [C005], its reliance on small tag sizes creates a high collision probability, limiting its utility as a hard security boundary [C000]. Conversely, CHERI provides byte-granularity protection and fault isolation [C002, C003], but its adoption is stalled by the need for capability-native memory allocators.
A second tension exists between spatial and temporal safety. Capability-based hardware effectively constrains out-of-bounds access [C004], but temporal safety (Use-After-Free) remains an expensive frontier [C004]. Implementing non-probabilistic temporal safety requires active revocation services like Cornucopia [C009]. This introduces a new tradeoff: practitioners trade simple pointer corruption for potential kernel-level race conditions and resource exhaustion within the revocation logic itself [C009].
Finally, practitioners face a "Semantic Gap" where the hardware ISA cannot inherently interpret a language's object model. Because the ISO C standard remains unclear on pointer provenance [C008], security guarantees are not automatic. They depend entirely on the practitioner's ability to accurately map provenance semantics onto hardware capabilities [C008]. Failure to achieve a verified mapping creates a risk of "false security," where developers assume hardware protection while remaining vulnerable to subtle mapping errors.
Opportunities
To replace probabilistic filtering with deterministic hardware-enforced safety, development must focus on bridging the gap between high-level logic and hardware-enforced memory safety.
Development Priorities
* Capability-Native Allocators: Current ports of open-source allocators to capability hardware often remain vulnerable. There is a need for allocators built from the ground up to support capability revocation, similar to the revoking allocator used in Cornucopia to achieve non-probabilistic temporal safety for heap allocations [C009].
* MTE-Backed In-Process Compartmentalization: For environments where a full ISA overhaul is impractical, ARM MTE can be retrofitted to implement capability-based in-process access control schemes [C005]. This provides a pragmatic path to isolating sensitive tool-chains without the cost of full capability hardware.
* Provenance Mapping Oracles: To prevent "false security" caused by the semantic gap between languages and hardware, tooling is needed to map C pointer provenance and memory object semantics directly onto hardware capabilities [C008].
Critical Research Questions
* MTE Performance Scaling: Can the microarchitectural causes of performance degradation in server workloads (e.g., RocksDB, Nginx) be resolved to make ARM MTE viable for high-throughput dispatch [C006]?
* Collision Mitigation: What hardware-software co-designs can reduce the high tag collision probability inherent in current tagged memory architectures to move beyond probabilistic safety [C000]?
* Revocation Scalability: While Cornucopia demonstrates low average overhead (<2%), how does the concurrent kernel-resident revocation service behave under extreme resource exhaustion or multi-processor race conditions [C009]?
References
- [C000] Multi-Tag: A Hardware-Software Co-Design for Memory Safety based on Multi-Granular Memory Tagging — https://doi.org/10.1145/3579856.3590331
- [C001] CheriRTOS: A Capability Model for Embedded Devices — https://doi.org/10.1109/iccd.2018.00023
- [C002] The CHERI capability model — https://doi.org/10.1145/2678373.2665740
- [C003] The CHERI capability model: Revisiting RISC in an age of risk — https://doi.org/10.1109/isca.2014.6853201
- [C004] What exactly do you mean bycapabilitybasedaddressingVs... — https://news.ycombinator.com/item?id=19838428
- [C005] CHERIvoke — https://doi.org/10.1145/3352460.3358288
- [C006] Capacity: Cryptographically-Enforced In-Process Capabilities for Modern ARM Architectures — https://doi.org/10.1145/3576915.3623079
- [C007] ARM MTE Performance in Practice (Extended Version) — https://arxiv.org/abs/2601.11786
- [C008] CHERI: A Hybrid Capability-System Architecture for Scalable Software Compartmentalization — https://doi.org/10.1109/sp.2015.9
- [C009] Exploring C semantics and pointer provenance — https://doi.org/10.1145/3290380