[flagged]
This doesn't read as a rant to me, but as calm and factual, regarding a genuine security regression that merits public attention. What is your interest in mischaracterizing it?
GrapheneOS says Pixel 11 has MTE support after all
51–60 of 175 posts
Re: GrapheneOS says Pixel 11 has MTE support after all
#52Shouldn't the headline read "GrapheneOS: Pixel 11 has bare minimum hardware level MTE support"?
As currently written, one would take away an entirely different message from the headline.
Re: GrapheneOS says Pixel 11 has MTE support after all
#53Unfortunately, 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?
I've read that there's a significant performance cost to MTE on Android (or on Tensor). It might just be that.
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.
Re: GrapheneOS says Pixel 11 has MTE support after all
#54[flagged]
You might not like their style of speech, at least they care about their users. Maybe Google uses nice flowery language that makes the reader feel nice—IDC—actions speak louder than words.
Stock Pixel is an awful experience. So many useless notifications, popups, ads, privacy not by default.
Company: "We care about your privacy" meanwhile 1400 corporations they share data with
GrapheneOS: "There's zero telemetry in GrapheneOS"
The more you read the more you realize they are nearly always correct.
Re: GrapheneOS says Pixel 11 has MTE support after all
#55To clarify, regarding the confusion: it was disabled , leading them to think it didn't outright exist. Why disabled? Well, its performance is apparently quite poor. But why? ...Apparently to save money.
The performance isn't really that bad but it's definitely a hit. The bigger issue is that it causes apps and services and occasionally also the kernel to throw MTE SIGSEGV which becomes a substantial problem if the developers for said apps or services don't care enough to fix them.
So the TLDR is that the main issue is that it causes a whole bunch of stuff to segfault when bad memory accesses occur but where they wouldn't segfault without MTE. It makes the phone feel unstable to average users since stuff just crashes with no real end-user-facing explanations.
Re: GrapheneOS says Pixel 11 has MTE support after all
#56It’s absurd that a small project like Graphene is able to run rings around a giant like Google in the security sphere. Almost makes you wonder if some of those vulnerabilities are intentionally allowed to exist. Vulnerabilities in the world’s most popular (by volume) mobile OS could provide a plausibly deniable global espionage backdoor.
There's a lot of speculation that US model censorship around "cyber capabilities" is about protecting an inventory of non-public vulnerabilities used for intelligence purposes. That same explanation could cover Google's MTE actions as a result of pressure from intelligence agencies. Nobody should be surprised if they prioritize what they see as national over personal security.
[deleted]
Re: GrapheneOS says Pixel 11 has MTE support after all
#57[flagged]
Even in the EU spyware use is prevalent (and i 'd guess everywhere else in the world). There have been many scandals of government authorized commercial spyware been deployed against journalists. Is it really that niche a mobile OS that tries to not be exploitable by them?
[flagged]
Re: GrapheneOS says Pixel 11 has MTE support after all
#58So not only a price increase: less RAM, performance scraping backwards, crippled/lost features, a camera system that captures stuttering audio and video imperfectly often, and Pixels dropping out of AOSP. Google Pixel has the marketshare it deserves.
There's no phone that isn't like that this year
Re: GrapheneOS says Pixel 11 has MTE support after all
#59Phones typically have 2 operating systems: one to handle telephonic functions like managing tower connections and separate operating system for user applications. The security implication here is that the telephonic operating system has access to the same system resources as the application operating system at the same time, right? The problem is your data is always available in plaintext to the telephonic OS because…
Most devices have a large number of operating systems. The camera also has one, and the storage has one if it's eMMC. The WiFi/BT chip has one. The AP has at least two, because of trustzone.
People bring up the baseband (ie. cell modem) having its own OS because someone gave a talk on it at defcon or something, but it's just one of many.
Re: GrapheneOS says Pixel 11 has MTE support after all
#60For anyone else not knowing what MTE stands for: > Memory safety bugs, which are errors in handling memory in native programming languages, are common code issues. They lead to security vulnerabilities as well as stability problems. >Armv9 introduced the Arm Memory Tagging Extension (MTE), a hardware extension that allows you to catch use-after-free and buffer-overflow bugs in your native code. https://developer.andr…
MTE is essentially hardware-accelerated AddressSanitiser[1]. [1]: https://clang.llvm.org/docs/AddressSanitizer.html
To expand a bit: 16-byte chunks of memory can be associated with a four bit tag. Then you steal four unused high bits from your pointers to store a tag value. When memory has a tag, a pointer used to access it must have the matching tag in its high bits. Your malloc implementation can then assign a different tag to adjacent allocations and any overflow into an adjacent allocation will have a mismatched tag and will trap. Likewise, change the tag on free and an attempt to use the pointer after the allocation has been freed will trap.
Of course, this doesn't come for free. Four bits per 16 bytes means a 3% increase in memory needed for tagged memory, hardware overhead for checking tags on memory accesses, and software overhead of setting/changing/clearing tags as necessary. This overhead is low (Apple shipped this in flagship hardware a year ago and nobody's complaining about performance there) but not zero, and an implementation with poor performance could be a real problem.