It's based on communication with them. We've had it directly communicated to us. There are also multiple Google security engineers/researchers who liked/retweeted our posts. Google has stated the Pixel 8 is the first platform with MTE available in production devices, so it's not a large jump to the hardened alternate OS available for it being the first to deploy it in production. We have ~250k users on Pixels, and the userbase on the latest generation with MTE is quickly growing. People on 4th/5th generation Pixels need to move on due to them being end-of-life (other than the Pixel 5a, which will be soon) and we're encouraging moving to the ones with the biggest hardware security improvement since we started. We're not making things up.

They could enable it for the whole base OS and apps opting into it. They have already fixed nearly all the bugs uncovered in regular usage. They did nearly all the work but didn't take it over the finish line due to performance and memory/cache usage concerns. Their security engineers did their job already. They have very talented people working for them. Our ability to ship this feature before them is because the performance and memory concerns are not significant enough to matter to us. We're more than willing to lose 3.125% memory/cache and we accept the performance overhead of asymmetric MTE which is in the ballpark of a few percent overhead in most cases rather than near 0% like asynchronous MTE. There are cases where asymmetric MTE has a larger overhead than a few percent, but it's not common. Async mode is nearly free. MTE may not be as low overhead on future Pixels. It depends on them deciding to prioritize MTE performance in their future custom CPU design. If they do not ship it in production, it's unlikely that they'll prioritize the performance. The overhead may increase from 0% for async and a few percent for asymm to a far more significant cost.

The performance argument against MTE being deployed in production and against supporting MTE at all is the argument that's relevant. There is no other significant reason not to ship it for the base OS and enable it for all their own apps in their manifests. Getting it enabled for the whole app ecosystem is a much bigger problem requiring multiple steps: 1) broad availability of MTE capable devices for app developers, 2) making it opt-out instead of opt-in for a future target API level so developers get around a year and a half to either opt-out or deal with it, 3) removing the opt-out for a future target API level so that developers cannot simply opt-out. We know that part is hard. We know that part involves documentation, developer relations, concerns about giving app developers too much to deal with too quickly, etc. It isn't what we expect them to do short term. What we want them to do is enabling the near 0 overhead sync MTE for Pixels by default, with it used in the base OS and Google apps opting into it. They already did most of the work, even years earlier via HWAsan testing.

We don't expect them to enable asymmetric MTE or keep track of tags to provide more deterministic guarantees as we're doing. We understand they don't want to sacrifice 5% overall performance, and don't expect them to, but they could provide an opt-in for asymmetric mode + better deterministic guarantees. Google can could do it for Android 15 if they make the decision to do it now. A reasonable prediction is that in a couple years Apple ships MTE support in hardware with async mode by default and asymm in lockdown mode, and then Google does the same. They have a chance to be a leader on a hardware security feature far more valuable than the PAC feature where iOS is years ahead.

Thanks for everything you do in security. You're a hero.

I feel like you're complaining, but it seems like Google has made historic advancements simply by pushing this technology to the point it's available and fixed most of not all crashes it finds. Stopping short of the goal by not enabling it on prod is likely a well reasoned choice. Google is highly committed to the underlying technology. It doesn't seem like the door to having it enabled in prod is forever closed and perhaps one day it'll happen. You don't have access to all of the information, so you're naturally going to jump to conclusions that might not actually be the best choice.

We have active communication with many people at Google about the areas we're heavily working on such as this and are not basing this on assumptions. You're talking about what you think happened based on your assumptions about it from lightly reading about it.

Most of the crashes were fixed via HWAsan before MTE existed in hardware. Their security people want MTE enabled in production. These issues were fixed before MTE and would have been fixed whether or not MTE was available in the standard ARMv9 cores/cache used by Pixels. MTE would likely already be enabled in production for the base OS (not user installed apps) if there weren't performance concerns. They clearly integrated it with that intention. We're more than capable of reading the commit messages and talking to engineers who worked on it along with other contacts there. They aren't keeping it a secret that there's a clear goal to enable MTE in production.

ARM provided MTE in their standard ARMv9 Cortex core designs. That's why MTE is available on the Pixel 8 and Pixel 8 Pro, because Tensor currently uses the standard core/cache designs. That's why MTE is not available for Snapdragon, and it's why it is theoretically available for MediaTek and Exynos.

The current availability of a high performance MTE implementation doesn't mean Google is highly committed to it. Pixels will be moving from standard Cortex core designs to their own core designs. There's an open question about whether MTE will be supported in the same way it is now. You're assuming that they're heavily committed to it and going to keep providing an extremely low overhead implementation. We have concrete reasons to be concerned.