[wwwigham]

Stock Pixel may not ship with it on by default for end users, but anyone can enable developer options and enable Memory Tagging Extensions - either until toggled off, or for a single session if you're trying to test a specific app - if you do want the feature on.

[strcat]

That's not the same as what's being used on GrapheneOS. It also excludes a significant portion of Bluetooth. Enabling support for memory tagging in the stock Pixel OS via developer options only makes it available for usage but doesn't actually use it. You also need to enable heap memory tagging via the Android Debug Bridge (ADB) shell via setprop. It provides no value through simply being enabled without using it to tag allocations. You can fully enable userspace heap MTE for the stock OS via the standard allocator implementation (Scudo) which is currently not particularly hardened. You can also use KASan via the MTE backend using setprop, but that's not designed for hardening right now and it's not clear it will ever be. There likely needs to be a separate MTE implementation for the kernel that's not part of KASan, which we haven't done yet for GrapheneOS either so MTE hardening is currently a userspace feature.

GrapheneOS uses our own implementation of hardware memory tagging for hardened_malloc with stronger security properties. In order to enable it by default for the base OS, we had to fix or work around various issues including this one. We use MTE in asymmetric mode across all cores rather than using asynchronous MTE for the main cores. Asymmetric mode is asynchronous for writes but synchronous for reads, which blocks exploitation properly rather than having a window of opportunity to succeed with exploitation. It gets checked on system calls and io_uring (another potential source of bypasses) is only available to 2 core system processes on Android via SELinux restrictions (fastbootd which is only used during installation and snapuserd used by the core OS after applying updates).

GrapheneOS always uses heap MTE for the base OS and apps known to be compatible with it. For user installed apps which are not in our compatibility database and which do not mark themselves as compatible, we provide a per-app toggle for enable MTE. Users can also toggle on using MTE by default for user installed apps which may not be compatible and can instead opt-out for incompatible apps. In order for this to be usable, we had to implement a user-facing crash reporting system. We did this in a way that users can easily copy a useful crash report to provide developers.

[ignoramous]

Some background on Sanitizers (ex: kasan) and ARM Memory Tagging Extension (mte) by the one of its developers, Andrey Konovalov:

https://youtu.be/KmFVPyHyfqQ / https://ghostarchive.org/varchive/KmFVPyHyfqQ

https://youtu.be/9wRT2hNwbkA / https://ghostarchive.org/varchive/9wRT2hNwbkA

[evanjrowley]

For my Pixel 7a, I searched the Developer Options menu three times and couldn't find it. Searching for Memory Tagging Extensions in Settings says it's there. Is it hidden somewhere?

Edit: Nevermind, I seen it's only for Pixel 8 phones: https://news.ycombinator.com/item?id=38125379

[strcat]

Enabling it via developer options is only the first step. You also need to enable it via setprop using ADB in the desired mode. The official documentation for using MTE on the stock Pixel OS is available at https://developer.android.com/ndk/guides/arm-mte. We strongly recommend this for app developers. It's a really easy way to find heap memory corruption in your apps, but you can use stack MTE without building the OS and your app with it.

We provided a user facing crash report system for memory corruption detected by MTE. MTE has no false positives. We strongly recommend users use the feature we provided for copying the crash report to report these bugs to app developers. App developers can replicate many of the bugs reported this way using either MTE on a Pixel 8 or a smaller subset by building their app with HWASan support.

Since many apps have latent memory corruption, we only enable it for the base OS, base OS apps and known compatible user installed apps by default. Users can opt-in to heap MTE for all user installed apps via Settings > Security and can then opt-out for apps with memory corruption occurring during regular use. Over time, we plan to add more apps like Signal/Molly known to be compatible to it into our app compatibility database so that it's force enabled for them by default without users enabling it in Settings > Security. The option to opt-out is only available for apps not known to be compatible with it, which is part of dealing with the issue of users potentially allowing it after an exploit attempt.

We're trying to convince Google to at least enable asynchronous MTE by default for the stock Pixel OS with user installed apps excluded from it unless they opt-in to it. The memory overhead is 3.125% and asynchronous heap MTE is near 0 performance overhead. Asymmetric heap MTE provides much better security but is more comparable to the overhead of a feature like legacy stack smashing protection. Stack MTE adds more overhead but SSP could be disabled to partly make up for it and deterministic protection of stack spills, return value, etc. can be provided through MTE instead since by not being tagged they have the 0 tag and everything tagged will be a random non-0 tag.

[m3drano]

is for Pixel 8 and above, since those have Tensor G3, which is armv9 IIUC.

[Sent1n3l]

Taken from the projects official Twitter they offer more than what is available by said toggle on stock:

They provide a nicer MTE implementation as part of hardened_malloc which uses the standard random tags with a dedicated free tag but adds dynamic exclusion of previous tag and current (or previous) adjacent tags. We also fixed Chromium's integration and will improve PartitionAlloc.

They also use it for their browser too using PartitionAlloc. Other Chromium-based browsers including Chrome don't use MTE since they don't really use the system allocators and have PartitionAlloc MTE disabled.

They are also continuing work on integrating more ARMv9 security features. MTE having the highest impact and being the most interesting of these features, but they're expanding usage of PAC and BTI. Android uses Clang's type-based CFI but not everywhere so BTI is still useful.