ARM MTE Performance in Practice (Extended Version)

TL;DR

This work delivers the first hardware-focused study of ARM MTE performance across diverse microarchitectures, revealing substantial, architecture-dependent overheads (up to $6.64\times$ in outliers) and identifying root causes such as store serialization, tag-check bottlenecks, and inconsistent store-to-load forwarding. It shows that MTE overheads are generally modest on many cores and workloads, but can spike dramatically on some Pixel cores and in ASYNC modes, with AmpereOne bugs and kernel interactions contributing additional costs. Beyond memory safety, the paper demonstrates both benefits (BufLock for TOCTOU, hardware-assisted memory tracing) and limitations (sandboxing and CFI tradeoffs), and provides practical fixes (kernel patches, selective tagging) plus a forward-looking MTE wishlist to guide future hardware and software design. The findings offer a concrete foundation for evaluating MTE adoption and inform hardware vendors and software developers on where to focus optimizations to improve performance and security balance in production systems.

Abstract

We present the first comprehensive analysis of ARM MTE hardware performance on four different microarchitectures: ARM Big (A7x), Little (A5x), and Performance (Cortex-X) cores on the Google Pixel 8 and Pixel 9, and on Ampere Computing's AmpereOne CPU core. We also include preliminary analysis of MTE on Apple's M5 chip. We investigate performance in MTE's primary application -- probabilistic memory safety -- on both SPEC CPU benchmarks and in server workloads such as RocksDB, Nginx, PostgreSQL, and Memcached. While MTE often exhibits modest overheads, we also see performance slowdowns up to 6.64x on certain benchmarks. We identify the microarchitectural cause of these overheads and where they can be addressed in future processors. We then analyze MTE's performance for more specialized security applications such as memory tracing, time-of-check time-of-use prevention, sandboxing, and CFI. In some of these cases, MTE offers significant advantages today, while the benefits for other cases are negligible or will depend on future hardware. Finally, we explore where prior work characterizing MTE performance has either been incomplete or incorrect due to methodological or experimental errors.

Figures (20)

• Figure 1: MTE overview. MTE allows assigning of 4-bit tags to each 16-byte memory granule. Subsequent reads from (or writes to) tagged memory must have the correct tag in bits[56:59] of the virtual address. An incorrect tag results in a fault in MTE SYNC, or a deferred fault in MTE ASYNC.
• Figure 2: Performance Cliffs Across MTE Impl. and Modes.MTE Overhead on SPEC CPU INT 2006 on Pixel 8 and AmpereOne and SPEC CPU INT 2017 on AmpereOne and Apple M5. Pixel SYNC mode incurs high overhead in some benchmarks. Certain ASYNC benchmarks also incurs high overheads, contradicting general expectations. Ampere and Apple's SYNC mode also shows some overhead spikes, albeit smaller.
• Figure 3: MTE-enabled Memcached performance on the AmpereOne. Memcached shows slowdowns of up to $1.40\times$; However, we found this is due to performance problems in the Linux kernel's MTE support, rather than hardware limitations.
• Figure 4: MTE server workload performance on AmpereOne after our kernel patch. MTE overhead are generally under $1.13\times$. Most importantly, our patch successfully addresses the Memcached regression shown in \ref{['fig:ampere-memcached']}, improving the worst case $1.40\times$ to about $1.05\times$ overhead.
• Figure 5: Uncovering structural hazards due to MTE ASYNC. Using a stride access pattern within small arrays stored in a linked list generates cache misses which stress the tag-load/tag-check operations in the Pixel Big Cores data path. This reveals structural hazards that bottleneck loads, slowdowns can be seen in the heatmap---lighter is slower.