Table of Contents
Fetching ...

NanoTag: Systems Support for Efficient Byte-Granular Overflow Detection on ARM MTE

Mingkai Li, Hang Ye, Joseph Devietti, Suman Jana, Tanvir Ahmed Khan

TL;DR

This paper investigates ARM MTE on Google Pixel 8, showing that its 16-byte tag granularity limits bug detection precision compared with software sanitizers like ASAN. To address intra-granule overflows, it introduces NanoTag, a system that detects memory-safety bugs at byte granularity by combining hardware checks with probabilistic software tripwires implemented with unmodified binaries. NanoTag achieves bug-detection parity with ASAN on the JulietTestSuite (around 97.6% for heap-based overflows) while preserving modest run-time overhead (~12.5% geomean on SPEC 2017) and zero additional memory footprint, largely due to its sampling-based tripwire mechanism and hardware-assisted checks. The approach demonstrates the practicality of byte-granular detection in production environments and highlights the potential to reduce production sanitizer overhead without sacrificing detection quality.

Abstract

Memory safety bugs, such as buffer overflows and use-after-frees, are the leading causes of software safety issues in production. Software-based approaches, e.g., Address Sanitizer (ASAN), can detect such bugs with high precision, but with prohibitively high overhead. ARM's Memory Tagging Extension (MTE) offers a promising alternative to detect these bugs in hardware with a much lower overhead. However, in this paper, we perform a thorough investigation of Google Pixel 8, the first production implementation of ARM MTE, and show that MTE can only achieve coarse precision in bug detection compared with software-based approaches such as ASAN, mainly due to its 16-byte tag granularity. To address this issue, we present NanoTag, a system to detect memory safety bugs in unmodified binaries at byte granularity with ARM MTE. NanoTag detects intra-granule buffer overflows by setting up a tripwire for tag granules that may require intra-granule overflow detection. The memory access to the tripwire causes additional overflow detection in the software while using MTE's hardware to detect bugs for the rest of the accesses. We implement NanoTag based on the Scudo Hardened Allocator, the default memory allocator on Android since Android 11. Our evaluation results across popular benchmarks and real-world case studies show that NanoTag detects nearly as many memory safety bugs as ASAN while incurring similar run-time overhead to Scudo Hardened Allocator in MTE SYNC mode.

NanoTag: Systems Support for Efficient Byte-Granular Overflow Detection on ARM MTE

TL;DR

This paper investigates ARM MTE on Google Pixel 8, showing that its 16-byte tag granularity limits bug detection precision compared with software sanitizers like ASAN. To address intra-granule overflows, it introduces NanoTag, a system that detects memory-safety bugs at byte granularity by combining hardware checks with probabilistic software tripwires implemented with unmodified binaries. NanoTag achieves bug-detection parity with ASAN on the JulietTestSuite (around 97.6% for heap-based overflows) while preserving modest run-time overhead (~12.5% geomean on SPEC 2017) and zero additional memory footprint, largely due to its sampling-based tripwire mechanism and hardware-assisted checks. The approach demonstrates the practicality of byte-granular detection in production environments and highlights the potential to reduce production sanitizer overhead without sacrificing detection quality.

Abstract

Memory safety bugs, such as buffer overflows and use-after-frees, are the leading causes of software safety issues in production. Software-based approaches, e.g., Address Sanitizer (ASAN), can detect such bugs with high precision, but with prohibitively high overhead. ARM's Memory Tagging Extension (MTE) offers a promising alternative to detect these bugs in hardware with a much lower overhead. However, in this paper, we perform a thorough investigation of Google Pixel 8, the first production implementation of ARM MTE, and show that MTE can only achieve coarse precision in bug detection compared with software-based approaches such as ASAN, mainly due to its 16-byte tag granularity. To address this issue, we present NanoTag, a system to detect memory safety bugs in unmodified binaries at byte granularity with ARM MTE. NanoTag detects intra-granule buffer overflows by setting up a tripwire for tag granules that may require intra-granule overflow detection. The memory access to the tripwire causes additional overflow detection in the software while using MTE's hardware to detect bugs for the rest of the accesses. We implement NanoTag based on the Scudo Hardened Allocator, the default memory allocator on Android since Android 11. Our evaluation results across popular benchmarks and real-world case studies show that NanoTag detects nearly as many memory safety bugs as ASAN while incurring similar run-time overhead to Scudo Hardened Allocator in MTE SYNC mode.

Paper Structure

This paper contains 30 sections, 8 figures, 6 tables, 1 algorithm.

Figures (8)

  • Figure 1: An overview of ARM MTE. Locks and keys represent memory and address tags, respectively. Addressable bytes are shadowed. The middle tag granule is a short granule. MTE detects both underflow ( 1) and overflow ( 3) across the tag granule boundary. However, it ignores the intra-granule buffer overflow ( 2).
  • Figure 2: CVE-2024-12084 cveexample, an intra-granule heap-based buffer overflow bug in rsync that becomes a silent data corruption in MTE, while both ASAN and NanoTag detect it.
  • Figure 3: Percentage of vulnerable memory allocations in SPEC CPU 2017 benchmarks. $86.57\%$ of all allocations in SPEC CPU 2017 benchmarks include short granules, leading to potential intra-granule buffer overflows. The only outlier is 505.mcf_r (0.05%).
  • Figure 4: NanoTag's workflow. Blue blocks specify additional components in NanoTag, while white blocks denote unmodified components in MTE's hardware and software.
  • Figure 5: NanoTag's sampling-based tripwire allocation.
  • ...and 3 more figures