Hardware-Assisted Memory Safety: Overview

Why Hardware?

#

Software-based memory safety defenses — sanitizers, ASLR, stack canaries, CFI — operate at the same privilege level as the code they protect. A sufficiently powerful attacker can disable or bypass them. Hardware-assisted approaches enforce safety properties below the software layer, in silicon that cannot be reprogrammed by an exploit.

Why this matters for AGIACC: for a security platform to matter commercially, it has to be deployable, low-overhead, and realistic for existing codebases. This comparison is the market map behind our technology choices.

The major hardware approaches can be grouped into three categories:

1. Tagging — Associate metadata tags with memory regions and pointers; check tags on every access (Arm MTE).
2. Signing — Cryptographically sign pointers to detect tampering (Arm PAC).
3. Capabilities — Replace raw pointers with unforgeable tokens that encode bounds, permissions, and provenance (CHERI).

Additionally, control flow enforcement hardware (Intel CET) and the now-deprecated Intel MPX offer narrower defenses for specific attack classes.

Comparison Table

#

Arm MTE (Memory Tagging Extension)

#

Introduced in ARMv9, MTE associates a 4-bit tag (16 possible values) with every 16-byte memory granule and with every pointer. On each memory access, hardware compares the pointer tag with the memory tag:

• Match → access proceeds normally.
• Mismatch → configurable response: trap (synchronous exception), async logging, or silent.

Strengths:

• Low overhead — suitable for always-on production deployment.
• Deployed at scale: Google Pixel 8/9, Apple iPhone 17 (Enhanced MTE / “Memory Integrity Enforcement”).
• Effective at breaking exploit chains by randomising tags on allocation and zeroing freed memory.

Limitations:

• Probabilistic — with only 4 bits, there is a 1/15 (6.7%) chance of an attacker guessing the correct tag.
• Tags are secrets — if leaked (e.g., via a side channel or format string), the defense is bypassed.
• Granularity is 16 bytes — cannot enforce sub-granule bounds.

→ For a deeper look, see Arm MTE in Practice.

Arm PAC (Pointer Authentication Codes)

#

Available since ARMv8.3, PAC uses cryptographic MACs to sign pointers stored in memory. Unused high bits of a 64-bit pointer carry a Pointer Authentication Code:

• When a pointer is created, the CPU signs it with a secret key and a context value.
• Before the pointer is used, the CPU verifies the signature.
• If the signature is invalid (pointer was tampered with), a trap is raised.

Strengths:

• Near-zero overhead (single instruction per sign/verify).
• Effective against ROP, JOP, and return address overwrites.
• Already shipping in billions of Arm devices.

Limitations:

• Does not enforce bounds — a valid pointer can still be used to access out-of-bounds memory.
• Key management attacks and signing oracle attacks can forge valid PACs in certain scenarios.

Intel CET (Control-flow Enforcement Technology)

#

Available since Tiger Lake (11th gen), CET provides:

• Shadow Stack — a hardware-maintained copy of return addresses. Any mismatch between the main stack and shadow stack triggers a fault, blocking ROP attacks.
• Indirect Branch Tracking (IBT) — indirect jumps and calls must land on ENDBRANCH instructions, preventing JOP attacks.

Strengths:

• Low overhead; transparent to most software.
• Effective against control flow hijacking.

Limitations:

• Only protects control flow — does not prevent data-only attacks, buffer overflows, or use-after-free.
• Coarse-grained IBT (any ENDBRANCH is valid) can be bypassed by sophisticated gadget chains.

Intel MPX (Memory Protection Extensions) — Deprecated

#

Intel MPX (2015–2019) added hardware bounds registers for performing spatial bounds checks on pointers.

• Why it failed: Average ~50% performance overhead, high memory usage for bounds tables, incompatible with many software patterns, and ultimately bypassable via Meltdown.
• Removed from Intel processors starting with the 10th generation (Ice Lake).
• Lesson: Hardware memory safety must be low-overhead and architecturally sound to achieve adoption.

CHERI (Capability Hardware Enhanced RISC Instructions)

#

CHERI replaces raw pointers with capabilities — 128-bit unforgeable tokens that carry:

• Base address and bounds (spatial safety)
• Permissions (read, write, execute, seal)
• Validity tag (1 bit, stored out-of-band — cannot be forged)
• Provenance (capabilities can only be derived from existing capabilities, never created from integers)

Strengths:

• Deterministic — violations are caught with 100% probability, not probabilistically.
• Secret-free — no tags to leak, no keys to steal.
• Compartmentalization — capability domains enable fine-grained in-process isolation.
• Low overhead — demonstrated at ~2–5% on Morello silicon, with some workloads showing negligible impact.

Status: Arm Morello (research), Microsoft CHERIoT (IoT), SCI Semiconductor ICENI (commercial RISC-V), CHERI Alliance (standardisation).

→ For a deeper look, see CHERI Deep Dive.

Key Takeaway

#

No single hardware technology solves every aspect of memory safety. In practice, these technologies are complementary:

• PAC is already ubiquitous and ideal for lightweight CFI.
• MTE provides always-on, probabilistic protection suitable for mass-market devices.
• CET strengthens x86 control flow integrity.
• CHERI offers the most comprehensive, deterministic protection — and is uniquely suited to safety-critical and security-critical systems like embodied AI.

AGIACC adopts the CHERI paradigm where we need deterministic guarantees for embodied and edge AI — not because one acronym solves everything, but because capability hardware is today’s most credible path from probabilistic mitigation to architectural containment for memory corruption.

Next: Arm MTE in Practice →