What is the CPU and memory performance overhead of Scudo with MTE enabled compared to standard malloc?

When compared to standard malloc implementations (such as glibc malloc or non-MTE jemalloc/Scudo), enabling ARMv9 Memory Tagging Extension (MTE) in the Scudo Hardened Allocator introduces low single-digit performance and memory overheads.

This represents a major leap over software-based sanitizers (like ASan or HWASan), which typically incur a $100\text{--}200\%$ execution penalty.

1. CPU Performance Overhead

The CPU overhead of Scudo with MTE depends heavily on whether the system runs in ASYNCHRONOUS (ASYNC) or SYNCHRONOUS (SYNC) mode.

                TYPICAL CPU PERFORMANCE OVERHEAD
+---------------------------------------------------------------+
| Standard Scudo / malloc | 0% (Baseline)                       |
| Scudo + MTE (ASYNC)     | 1% - 3%                             |
| Scudo + MTE (SYNC)      | 3% - 6%  (up to ~15-20% full-stack)|
| HWASan / ASan           | 100% - 200%                         |
+---------------------------------------------------------------+

Primary CPU Bottlenecks

1. Instruction Execution Penalty during malloc / free:

   • Generating tags using IRG (Insert Random Tag).

   • Writing tags to physical RAM tag arrays using STG (Set Tag), ST2G, or STGP (Set Tag and Pair).

2. Memory Bus & Cache Traffic:

   • Checking hardware tags during every LDR (Load) and STR (Store) instruction adds minor bus validation cycles.

3. Allocation Event Logging in SYNC Mode:

   • In SYNC mode, Scudo captures allocation and deallocation call stacks to produce detailed error tombstones upon failure. This stack unwinding adds additional CPU cycles during high-frequency allocation loops.

2. Memory Footprint (RAM) Overhead

Total memory overhead for Scudo + MTE typically ranges between $3\%$ and $5\%$ over standard malloc.

                 TOTAL PHYSICAL MEMORY OVERHEAD
+---------------------------------------------------------------+
| Hardware Tag Reservation (Bootloader) | 3.125% of System RAM |
| Scudo Chunk Header Metadata           | 8 - 16 bytes / chunk |
| 16-Byte Granule Padding               | Variable             |
+---------------------------------------------------------------+

Primary Memory Drivers

1. Hardware Tag Storage (RAM Carving):

   • MTE assigns a $4$-bit tag to every $16$-byte ($128$-bit) granule of physical memory.

   • Calculated Overhead: $\frac{4 \text{ bits}}{128 \text{ bits}} = 3.125\%$ of system RAM. This memory is reserved by the bootloader/kernel upon startup solely for MTE tag storage.

2. Mandatory 16-Byte Alignment & Granule Padding:

   • Standard malloc can service $4$-byte or $8$-byte allocations without padding.

   • Scudo + MTE enforces a strict $16$-byte minimum alignment to match the hardware tag granule. Requesting $4$ bytes results in $12$ bytes of internal padding.

3. Scudo Chunk Header Overhead:

   • Every active heap chunk includes an $8$-to-$16$-byte Scudo metadata header storing chunk size, allocation state, and CRC32 checksums.

4. Quarantine / Delayed Deallocation (Optional):

   • When Scudo's quarantine feature is enabled to prevent rapid Use-After-Free address recycling, freed blocks are held briefly before release. This temporarily increases the process's Resident Set Size (RSS).

3. Comparative Trade-offs: Scudo + MTE vs. Alternatives

Allocator / Mitigation
CPU Overhead
Memory Overhead
Detection Capability
Production Deployable?

Standard malloc / Scudo (MTE Off)
$0\%$ (Baseline)
$0\%$ (Baseline)
None
Yes

Scudo + MTE (ASYNC Mode)
$1\% - 3\%$
$3\% - 5\%$
High (asynchronous trap)
Yes (Default for apps/services)

Scudo + MTE (SYNC Mode)
$3\% - 6\%$
$3\% - 5\%$
$100\%$ exact fault location
Yes (Testing / High-security apps)

HWASan (Hardware-Assisted ASan)
$\sim 100\%$
$15\% - 30\%$
$100\%$ exact fault location
No (Development only)

ASan (AddressSanitizer)
$100\% - 200\%$
$50\% - 100\%$
$100\%$ exact fault location