Unfortunately, the headline is somewhat optimistic compared to the reality, I think.

The thread makes it sound like it could have been disabled due to errata or performance issues. Basically, it looks like the software Google is shipping intentionally doesn't use MTE on the Pixel 11 hardware. That raises the question of...what does Google know is wrong with MTE on the Pixel 11?

▲

GeekyBear 4 days ago | parent | next [-]

> it looks like the software Google is shipping intentionally doesn't use MTE on the Pixel 11 hardware. That raises the question of...what does Google know is wrong with MTE on the Pixel 11?

Apple replaced MTE with an upgraded version that can run in synchronous mode all the time without the performance hit.

> Consider that MTE can be configured to report memory corruption either synchronously or asynchronously. In the latter mode, memory corruption doesn’t immediately raise an exception, leaving a race window open for attackers... We believe memory safety protections need to be strictly synchronous, on by default, and working continuously.

https://security.apple.com/blog/memory-integrity-enforcement...

Google may just be getting ready to follow suit.

	▲	protimewaster 4 days ago \| parent [-]
		> Google may just be getting ready to follow suit. That may well be, but it's a regression for the time being, since Advanced Protection mode presumably no longer uses MTE (or a replacement for MTE), whereas it did on the Pixel 8, 9, and 10. It seems like they should've continued to offer MTE until the replacement was ready.

▲

Yokolos 4 days ago | parent | prev | next [-]

I've read that there's a significant performance cost to MTE on Android (or on Tensor). It might just be that.

▲

OneDeuxTriSeiGo 4 days ago | parent [-]

There's only a significant cost to synchronous MTE.

MTE ships two modes. synchronous mode and asynchronous mode. SYNC is slower but gives you far better traces and throws an SEGV_MTESERR as soon as violations happen. ASYNC however is async so there's a bit of a delay between a violation and the "catch" that throws SEGV_MTEAERR.

Strictly speaking async is worse for security because there's a brief window of time where the process "gets away with it" but the main differentiator is that because things don't stop the moment the violation occurs, SEGV_MTEAERR traces tend to be some degree of "out of date" vs SEGV_MTESERR which capture the exact state of the world the moment the error occurs.

The main tradeoff here is that async MTE has basically negligible cost. Something like 1-5% in practice but in microbenchmarks you can see up to 50%. Vs synchronous MTE where the penalty is on average closer to like 10-15% but in microbenchmarks it can be like 5-6x slower.

So yeah the perf cost is there but it's really not a major issue.

------------

The main issue is that apps and services crash when an MTE segfault occurs. So this means that to the uninformed end user apps appear spuriously unstable with no meaningful context. And it's not just apps. On graphene I see MTE segfaults semi regularly from various system daemons (mainly related to GPS/nav) and occasionally in Google Play Services itself.

From time to time I get them in Youtube and I constantly get them in the Twitch app. It's very annoying and the apps just crash when you happen to do some particular action leaving you walking on your toes to avoid accidentally tapping whatever magic pattern happens to invoke a MTE SIGSEGV until the next update. Doubly so since most apps provide no meaningful interface for uploading log traces to report these issues.

-------------

If Google wanted to roll this out without the spurious crashes they'd need to deploy it and eat the minor perf hit but they'd need to register a global signal handler to capture these MTE SIGSEGVs and report them back to the services in question without crashing the app.

And most app devs don't care so they'd be taking a minor (or major) perf hit in exchange for logging errors that developers always ignore. Doubly so in the modern day of "just have AI fix/do XYZ and who cares about the consequences as long as it runs".

I'm not surprised they dropped it but I do honestly wish they'd forced the issue and just deployed it and forced apps to fix their shit.

▲

bjustin 4 days ago | parent | next [-]

Given the current use of AI tools I would think that SEGV_MTESERR crashes would be low hanging fruit to fix. AI tools do ok with identifying memory corruption issues, given a smoking gun, in my experience.

	▲	OneDeuxTriSeiGo 4 days ago \| parent [-]
		SEGV_MTESERR is reasonably low hanging fruit until it's in a binary blob and the IC manufacturer said service interfaces with refuses to do anything to fix it. Likewise if it's because a language is being lazy with how it handles memory (see: wireguard-go SEGV_MTESERR because golang's string implementation was being overly permissive with pointers). And of course this only applies to SEGV_MTESERR. SEGV_MTESERR has a much higher runtime overhead that Google and co would not tolerate (but Graphene does) so they'd likely only be willing to use SEGV_MTEAERR which provides traces that point at a completely different place than where the fault occurred (but still provide a little bit of useful info).

▲

ysnp 4 days ago | parent | prev [-]

Are there any alternatives for a similar runtime security improvement?

▲

worldsavior 4 days ago | parent | prev [-]

Nothing is wrong. They just don't use MTE yet, they probably have other priorities. They wanted to save some costs until they will use MTE, so they removed some hardware acceleration and downgraded the GPU. Simple as that.

	▲	protimewaster 4 days ago \| parent \| next [-]
		AFAIK the other Pixel devices, going back to the 8, do use MTE in the stock OS. Some MTE features are only enabled when "Advanced Protection" is turned on in the OS settings, but the stock OS on those devices does make use of MTE. In the Android documentation, MTE is explicitly called out as one of the protection features enabled in the Advanced Protection mode. So, I don't think it's accurate to say they don't use it yet. They were using it, and then they stopped. I think that's one of the reasons the linked GOS thread says they're concerned that "MTE may actually be broken due to CPU errata".
	▲	microtonal 4 days ago \| parent \| prev [-]
		And axed 4GB of RAM. In many ways, the Pixel 10 Pro is the better device for running GrapheneOS (and maybe even Pixel UI). Well done Google! The thermometer was nice too if you have kids.