Live data from Hacker News

GrapheneOS says Pixel 11 has MTE support after all

grapheneos.social

111–120 of 175 posts

Re: GrapheneOS says Pixel 11 has MTE support after all

#111
post #48

[flagged]

Perhaps they complain because that's literally the only way to get Google to take notice? Let's be real, AOSP doesn't exist any more. Google have closed down nearly everything. All the development happens in private, you've stopped addressing bugs raised by the public, the source of patches are only infrequently released, device trees are gone. Wouldn't you complain?

All the development happens in private, you've stopped addressing bugs raised by the public, the source of patches are only infrequently released, device trees are gone.

To emphasize this point a bit more: only "QPR0" (major release) and QPR3 are released as part of AOSP. QPR1 and QPR3 are not released at all anymore, but contain fixes for vulnerabilities that are not marked high/critical (so don't end up in ASB). It is not clear to me whether OEMs get access to QPR1 and QPR3, but Google are not only witholding features, but also a set of security fixes.

Besides that, they are torpedoing other systems through Play Integrity.

IMO it would be best if AOSP was spun off from Google into its own org that actually cares about developing an open source system for others (both open source systems like GrapheneOS/Lineage and commercial vendors like Samsung) and that would have an attestation system that is open to vendors that have good device security.

Re: GrapheneOS says Pixel 11 has MTE support after all

#112

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?

> 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 t…

> 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.

Re: GrapheneOS says Pixel 11 has MTE support after all

#113
post #89

Earlier quoted context omitted.

Do we know if Google is operating on the frontier of the trade-off curve? What do we lose from Pixel Android when GrapheneOS security changes are made?

Actually functionality, stability of apps and features people use.

What functionality and features are lost in the base Pixel OS (not apps) as a direct result of GrapheneOS's changes to AOSP?

Re: GrapheneOS says Pixel 11 has MTE support after all

#114
post #104

Earlier quoted context omitted.

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 G…

[flagged]

> If they happen to overlap, that's a happy coincidence.

I can't know what the developers of any OS are actually thinking, but based their actions, GrapheneOS does more for their users than any other OS.

Therefore I assume that doing good things for users equals care for users. It's probably stupid to try to guess about care.

Re: GrapheneOS says Pixel 11 has MTE support after all

#115
post #36

[flagged]

[flagged]

I'm not an AOSP engineer, but that was my thought reading GOS's comments: Why be negative toward the people who you want help from?

What help though? Google has closed off AOSP and only does source code drops twice a year. Google has embargoed security patches for three months and only provides them to OEMs of Google-certified Android phones, not other AOSP-based projects. Google stopped providing git trees of kernel sources and instead requires projects to submit a request for a Google drive link for each kernel version that takes up to weeks to process. Google is shutting out open Android systems through Play Integrity.

Google is not helping anymore, over the last 1-2 years they have tried everything to sabotage AOSP-based projects. The only reason that they are not fully closing AOSP is probably because 1.) they would get in hot water with regulators; and 2.) AOSP will probably get forked.

Re: GrapheneOS says Pixel 11 has MTE support after all

#116

So 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

Yet, you can pick up a Samsung S26 for 600 Euro that will absolutely demolish a Pixel 11 in practically every aspect except cameras. Years ahead in CPU/GPU performance, etc.

Yet no GrapheneOS.

Re: GrapheneOS says Pixel 11 has MTE support after all

#117
post #91

Earlier quoted context omitted.

If they're just some "niche use case" then why would Motorola partner with them? The way they see it, > By combining GrapheneOS’s pioneering engineering with Motorola’s decades of security expertise, real‑world user insights, and Lenovo’s ThinkShield solutions, the collaboration will advance a new generation of privacy and security technologies. In the coming months, Motorola and the GrapheneOS Foundation will contin…

[flagged]

I think that's a worthwhile point to consider but it's only relevant if we move the goalposts from "GrapheneOS is only used by Android ROM enthusiasts" to "GrapheneOS is only supported by one small Android phone manufacturer".

To be frank, though, I don't see any of this line of reasoning as relevant; it's just appeals to greater authorities on either end. If AOSP is only for manufacturers there's really no reason for it to be open source in the first place. And then folks who care about actually improving security end-to-end outside of whatever's convenient to implement by those beholden to the quarterly profit metrics are up a creek.

Personally, if this whole GrapheneOS/Motorola thing doesn't improve the state of the ecosystem I'm going back to Apple or whatever other manufacturer makes it clear they take security seriously.

Re: GrapheneOS says Pixel 11 has MTE support after all

#118

[flagged]

> people that flash custom Android OSs are the very definition of niche users.

This is a mischaracterization. The niche isn't Android hobbyists, it's people with what should be a basic expectation for privacy. I wouldn't flash GOS or any other OS if I could safely avoid it.

Re: GrapheneOS says Pixel 11 has MTE support after all

#119
post #80

Earlier quoted context omitted.

Elsewhere in the thread, someone reports that with MTE enforcement enabled, there are lots of crashes. And app and system service developers don't seem responsive to them. That's not something that's really acceptable on a $500+ phone... so if you're Google, you're not going to turn that on by default and you're not really going to be interested in keeping it as a feature that users can turn on. Graphene has a differ…

Why not force it on an API change? It wouldn’t be the first time there was a breaking change.

Because it (anecdotally) crashes too much, but only on $$$ devices with cool CPUs that can use it. People buy expensive phones because they're supposed to work better.

They should really do some sort of sampling thing to generate crash dumps and find big offenders and increase the coverage over time.

For Google employee devices, 0.1% of background execution starts while charging in an idle period (overnight bedtime charging) will use MTE. When any specific device hits an MTE crash, back-off sampling for 1 week on that device. Modulate the sampling rate so crashes are manageable.

When Google employee devices are not crashing overnight at a high rate, then start sampling background execution during the day for employees and overnight background execution on general user devices. Finally, sample on foreground execution, again for Google employee devices first.

If there's significant variation in crashes by app, you probably need to setup a way to set sampling rates to zero or very low for application versions that have been identified as a known problem and don't need additional traces.

Re: GrapheneOS says Pixel 11 has MTE support after all

#120

Earlier quoted context omitted.

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 t…

What does the malloc or hardware do if for some reason your program needs to access memory addresses that overlap your tag bytes ? I know that it's a really improbable scenario and the OS would also just refuse you allocations at some point, but what would the malloc implementation and the MTE do in such a case ? Fail the allocation ? trap when reading the pointer since it would point to the "wrong place" ?

If you mean the memory that stores the actual tags associated with each 16-byte chunk of memory, that's a separate region that should be inaccessible except for using the special instructions for reading/writing tags.
Post reply on HN