How does ARMv9 Memory Tagging Extension (MTE) work alongside VBS Enclaves to prevent buffer overflows?

While Virtualization-Based Security (VBS) Enclaves protect sensitive data by isolating an entire region of memory from the host operating system, ARMv9 Memory Tagging Extension (MTE) hardens the internal memory safety of the code running inside that enclave.
Together, they form a defense-in-depth model: VBS provides macro-level isolation (keeping external malware out), while MTE provides micro-level memory protection (preventing software bugs inside the enclave from being exploited).
1. How ARMv9 MTE Works at the Hardware Level
ARMv9 MTE implements fine-grained, hardware-assisted memory safety by assigning metadata "tags" to memory pointers and memory locations:
POINTER (64-bit)
+----------------+-------------------------------------------------+
| Tag (4 bits) | Address Bits (60 bits) |
+----------------+-------------------------------------------------+
|
| Hardware match check on Load/Store
v
+----------------+-------------------------------------------------+
| Tag (4 bits) | 16-Byte Physical Memory Granule |
+----------------+-------------------------------------------------+
PHYSICAL RAM / ENCLAVE MEMORY
-
Physical Memory Allocation Tags: Physical memory is divided into $16$-byte blocks called granules. The CPU assigns a $4$-bit tag (one of $16$ possible values, $0\text{x}0$ through $0\text{x}F$) to each granule.
-
Pointer Tags: When memory is allocated (via heap or stack), the upper unused byte of the $64$-bit memory pointer stores a corresponding $4$-bit pointer tag.
-
Hardware Match Enforcement: Every time the CPU executes a
LDR(load) orSTR(store) instruction, the hardware automatically compares the pointer's tag against the target memory granule's tag. -
Instant Fault on Mismatch: If the tags do not match, the CPU raises an immediate hardware exception (a synchronous
SIGSEGVor hardware trap), halting execution before the memory access can complete.
2. Catching Buffer Overflows & Use-After-Free
MTE directly neutralizes spatial and temporal memory safety bugs:
Spatial Memory Errors (Buffer Overflows)
When two adjacent variables or buffers are allocated in memory, the allocator assigns them different random $4$-bit tags.
-
If a buffer overflow occurs and a pointer attempts to write past Buffer A ($Tag = 0\text{xA}$) into the memory space of adjacent Buffer B ($Tag = 0\text{xB}$), the pointer's tag ($0\text{xA}$) will not match Buffer B's memory tag ($0\text{xB}$).
-
The hardware catches the mismatch on the very first byte that crosses the boundary. Because tags are randomized across $16$ values, MTE has a statistical detection rate of $\frac{15}{16} \approx 93.75\%$ for blind out-of-bounds memory accesses.
Temporal Memory Errors (Use-After-Free)
When memory is deallocated (freed), the memory allocator changes the tag of that $16$-byte memory granule to a new value (or an invalid tag).
-
If a dangling pointer carrying the old tag tries to read or write to that freed memory, the tags no longer match, instantly stopping Use-After-Free (UAF) exploit chains.
3. How MTE & VBS Enclaves Work Together
A major challenge with VBS Enclaves is the internal trust boundary. VBS Enclaves isolate VTL1 (Virtual Trust Level 1) memory from VTL0 (the standard OS and user applications). However, the enclave must still accept data passed to it from the untrusted host OS (VTL0).
+-------------------------------------------------------------------------------+
| VBS ENCLAVE (VTL1) |
| |
| [ Untrusted Input from Host (VTL0) ] |
| | |
| v |
| [ Enclave C/C++ Code ] ---> Triggers Heap Buffer Overflow |
| | |
| v |
| [ ARMv9 MTE Hardware ] |
| Tag Mismatch (0xA != 0xB) |
| | |
| v |
| [ INSTANT CPU ENCLAVE ABORT ] |
| (Exploit fails, Keys remain safe) |
+-------------------------------------------------------------------------------+
1. Stopping "Host-to-Enclave" Exploit Vectors
If an attacker running malware in VTL0 wants to extract encryption keys or Recall snapshots from inside a VBS Enclave, they cannot read the memory directly due to hypervisor blocks. Instead, they must send specially crafted, malformed inputs across the enclave boundary to trigger a buffer overflow or memory corruption bug inside the enclave's C/C++ runtime.
-
With MTE enabled inside the enclave: The moment the untrusted host input causes an enclave pointer to overflow its allocated $16$-byte granule inside VTL1, the ARMv9 hardware detects the tag mismatch and terminates the enclave immediately. The exploit chain breaks before the attacker can achieve arbitrary code execution inside VTL1.
2. Zero-Latency Memory Hardening
Software-based memory sanitizers (like AddressSanitizer / ASan) add $2\times\text{--}3\times$ CPU overhead and massive memory bloat, making them unusable in production environments.
-
ARMv9 MTE performs tag checks directly inside the CPU pipeline's Load/Store execution units with less than $1\text{--}2\%$ performance overhead and a tiny $\sim3\%$ memory overhead for tag storage. This allows production VBS Enclaves to run fully hardened memory protection in real time without degrading performance.
Summary of Roles
Security Boundary
VBS Enclave (Hypervisor Level)
ARMv9 MTE (Hardware Level)
Primary Target
External isolation ($VTL0 \leftrightarrow VTL1$)
Internal code execution safety
What It Prevents
Unlawful memory reads/writes by admins, malware, or compromised OS drivers
Buffer overflows, out-of-bounds writes, and Use-After-Free bugs
Enforcement Layer
Hyper-V Hypervisor (Stage 2 Page Tables)
ARMv9 CPU Pipeline & Memory Controller
Reaction to Attack
Blocks page-table access; access denied
Hardware CPU trap/exception; terminates process immediately
Comments
Post a Comment
Do not insert clickable links or your comment will be deleted. Checkbox Send me notifications to be notified of new comments via email.