Operating system security is a constant battle against memory corruption. Software safeguards like ASLR, stack canaries, and non-executable memory have been used, but attackers find ways around them. With Android 17, Google now mandates hardware memory tagging for ARMv9 chips, marking a shift to hardware-based security for future mobile devices.
Android 17 now requires the Memory Tagging Extension (MTE), a hardware feature in ARMv9-A. By moving memory safety checks to the CPU, this aims to eliminate major vulnerabilities like use-after-free and buffer overflows, which account for most serious Android security bugs.
How MTE Changes Memory Safety
To understand MTE’s importance, consider C and C++. Memory is accessed via pointers, which are just addresses. The CPU cannot detect if a program uses an address after it is freed.
With memory tagging, each 16-byte block has a 4-bit tag. When memory is allocated, the allocator assigns a tag and stores it in the unused part of the pointer. The CPU checks whether the memory and pointer tags match on access, triggering a fault if they don’t.
Hardware tags are checked at a low level, making bypass difficult. This prevents heap grooming, as attackers must guess 4-bit tags at each step, thereby greatly increasing the difficulty of the attack.
Android 17: Making MTE Mandatory
MTE was first added in Android 12, but its use has been inconsistent. Google’s Pixel 8 and Pixel 9 phones were among the first to include MTE hardware, but the feature was often hidden as a Developer Option or only enabled for certain system services like Bluetooth and NFC.
The Android 17 source code shows that MTE is no longer optional. Any device that wants Google Mobile Services (GMS) certification on ARMv9 chips must have MTE turned on by default for all important system processes and core software. There are also new ‘Hardened User-Space’ profiles that require MTE for third-party apps unless they opt out. This strong approach is meant to push chip makers and device manufacturers to enable MTE, even if they worry about performance.
Optimizing Security and Performance: Three MTE Modes
One main reason memory tagging has been slow to catch on is the ‘security tax,’ or the extra CPU and battery use it can cause. Android 17 handles this by using three different MTE operating modes:
- Synchronous (SYNC) Mode: In this mode, the CPU immediately halts execution whenever it encounters a tag mismatch. This makes it the most secure option, as errors are caught at the moment they occur. However, this strict checking also causes the most slowdown, with a performance cost of about 3% to 5%. For this reason, Android 17 requires SYNC mode only for the system’s most security-critical parts, including the kernel, identity credentials, and biometric authentication.
- Asynchronous (ASYNC) Mode: In this mode, the CPU records a tag mismatch but does not stop immediately. Instead, execution continues until the next kernel entry, commonly during a system call. This delayed response reduces performance impact but means violations are detected slightly later. Android 17 assigns ASYNC mode to regular system apps and background services, prioritizing the user experience for less-critical operations.
- Asymmetric (ASYMM) Mode: This mode combines the earlier modes by applying synchronous checks for reading memory (CPU catches errors immediately on reads) and asynchronous checks for writing (delayed error reporting for writes). Android 17 uses ASYMM as the default for most third-party apps, since it balances strong protection—especially for data reads without the higher performance costs of full synchronous checking.
Why ARMv9 Chips Matter for Security
This rule focuses on ARMv9 chips because their hardware, like the Cortex-X4, A720, and the new Blackhawk cores, is built to check tags quickly. Older ARMv8.5 versions of MTE were often too slow for actual use, but improvements in ARMv9 have made the performance impact so small that most users will not notice it.
This new requirement is also a key defense against the growing number of ‘zero-click’ attacks. Many of these target media processing or networking, which often use C++ for speed. By making hardware memory safety mandatory in these risky areas, Android 17 makes it much harder and more expensive for attackers to succeed. An exploit that worked on an older ARMv8 device will now just cause a harmless crash on an Android 17 ARMv9 device.
What This Means for Developers: Fewer ‘Heisenbugs’
For developers, making MTE mandatory has both pros and cons. It gives them a strong new way to debug, turning hard-to-find ‘Heisenbugs’ into clear, repeatable crashes. But it also means developers need to be more careful with native code. Custom memory allocators that do not handle tags properly will not work with Android 17.
To help with this change, the Android 17 SDK now offers improved ‘MTE-Aware’ telemetry. When a tag fault happens, the system creates a detailed report with the allocation and freeing stack traces for the problem to address. Before, this kind of insight into memory use was only possible with sophisticated tools like AddressSanitizer (ASan).
Conclusion
The discovery that the Android 17 source code mandates hardware memory tagging for ARMv9 silicon marks the beginning of the end for memory corruption as we know it. The fact that Android 17 now requires hardware memory tagging for ARMv9 chips signals a major step toward ending memory corruption. By making MTE a required part of the platform, Google is shifting from a ‘detect and patch’ approach to one that is secure by design. It will focus on MTE performance, and app developers will finally have a hardware-backed safety net that protects their users from the most dangerous classes of cyberattacks. The “black art” of memory exploitation is about to get a lot more difficult.
Source: Arm memory tagging extension
