GrapheneOS finds Bluetooth memory corruption via ARM MTE

Longer answer:

Google folks were responsible for pushing on Hardware MTE in the first place - It originally came from the folks who also did work on ASAN, syzkaller, etc. They are not in Android, but it was done with the help and support of folks in Android. That's the Google side, it was obviously a partnership with ARM/etc as well.

I was the director for the teams that created/pushed on it, way back when - this was years ago at this point because of the lead times on a hardware/architecture feature like this.

So i'm very familiar with the tradeoffs.

It is more than just the memory usage or cache. The post is correct that it was designed to be able to be enabled/disabled dynamically, and needed to have expected perf cost ~0, but the main use case at the time was sampling based bug finding.

That is, if you turn MTE on (whether servers, phones, whatever) for 1% of the time for your entire fleet, and you have a large enough fleet, you will find basically all bugs very quickly. You can do this during dogfooding, etc.

Put another way - the goal was to make it possible to use have the equivalent of ASAN be flipped on and off when you want it.

Keeping it on all the time as a security mitigation was a secondary possibility, and has issues besides memory overhead.

For example, you will suddenly cause tons of user-visible crashes. But not even consistently. You will crash on phones with MTE, but not without it (which is most of them).

This is probably not the experience you want for a user.

For a developer, you would now have to force everyone to test on MTE enabled phones when there are ~1 of them. This is not likely to make developers happy.

Are there security exploits it will mitigate? Yes, they will crash instead of be exploitable. Are there harmless bugs it will catch? Yes.

But keep in mind what i said at the beginning - i would not assume they don't use it.

I would instead assume they don't necessarily use it in production on all the time.

Anyone who has experience on hardware feature bringup of this kind will tell you the fact that they can boot and run the system and only when they do this one thing does it crash under MTE is actually a very good sign they do use it.

Otherwise it would have probably crashed a million times :)

As an aside - It's also not obvious it's the best choice for run-time mitigation.

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.

https://grapheneos.org/features

CalyxOS is not a hardened OS. It greatly reduces security vs. AOSP via added attack surface, rolled back security and slow patches. CalyxOS does not have features like this. It does the opposite of this.

Compatibility with Android apps on GrapheneOS is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer:

https://grapheneos.org/usage#sandboxed-google-play

Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the problematic microG approach.

https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.

https://privsec.dev/posts/android/choosing-your-android-base... is an article with more long form comparisons between OSes.