GrapheneOS finds Bluetooth memory corruption via ARM MTE

Yes, we want GrapheneOS devices meeting the same security standards we've set based on the baseline provided by Pixels while also including additional features we want to have. Pixels are not the best possible hardware but rather the best available hardware by far. There are no other devices even coming close to the current requirements. iPhones come close but are missing major things like MTE which we expect and of course don't have any alternate OS support and their security APIs are the ones needed by iOS which wouldn't work for what we need.

> meets their security requirements

Worth noting that there are privacy requirements listed there too including this one:

> Wi-Fi anonymity support including MAC address randomization, probe sequence number randomization and no other leaked identifiers

We could list a lot of other privacy, security and performance requirements which we take for granted. We're trying not to be overly strict with the requirements and are trying to keep it simple.

> If a phone met those requirements and was not made by Google, GrapheneOS would consider supporting it. In the case that Google didn't meet the requirements but a different phone did, GrapheneOS would support that phone and not the Pixels.

This is a factor in us advocating for MTE and other features even if they exist in a form we can use today. We do not take it for granted that future Pixels will continue providing what we expect. We push them to continue doing it and to keep important features we need. We know they're moving away from ARM Cortex cores to their own cores and we want them to provide an equally good MTE implementation. This means we need to advocate for MTE and get other people to advocate for MTE. If people eventually want to have CHERI and other more aggressive memory safety features, please advocate for what they've already shipped. Google enabling asynchronous MTE in production for their own code would be a huge security boost for Pixels and would also help assure that it has a future instead of being treated as a debugging feature they don't need to support on all their devices.

Highly recommend that any Android developer with a single native library shipped with their app gets a Pixel 8 or Pixel 8 Pro to use MTE for finding and debugging memory corruption bugs. One of the major advantages of MTE is that you can use heap MTE with instrumentation only added to the allocators (such as malloc) without building all the code with it. Stack allocation MTE of course requires instrumenting those stack allocations.

> I still wish they'd release "GrapheneOS Minus" (in the vein of uBlock Origin Minus[0]) so a much larger audience could have 95% of the security benefits they'd have on Pixel hardware.

It would not be anywhere close to providing 95% of the security benefits. In fact, it would largely be reducing security as the baseline without the hardware having proper alternate OS support. If you unlock a Samsung phone, the next closest to meeting our requirements, you cripple the device's security. Many of the hardware security features aren't available for an alternate OS and some even remain permanently disabled if you lock with the stock OS again. How can we support a device like that? Many of these hardware security features are what the OS security features are built on. Our work on integrating MTE into hardened_malloc and turning Android and Chromium's MTE support into something that can be used in production doesn't do any good on a device with no MTE, but this applies far beyond MTE. MTE alone is a significant part of the exploit protection advantages we're providing and is going to grow as we do more MTE integration work including potentially getting stack allocation MTE enabled in a way that doesn't break app compatibility (stack scanning by GC, etc.).

Recommend reading through our security requirement list. It will make much more sense. It's not an exhaustive list of what we require but is what we were able to turn into clear concrete requirements which should be expected for all reasonably secure mobile devices.