GrapheneOS says Pixel 11 has MTE support after all

user_7832

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

chekibreki

For 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.android.com/ndk/guides/arm-mte

m00dy

For those don't know you will either code in Rust or make sure MTE enabled.

greesil

Boo. I was delighted by its introduction in pixel 8. I thought this was a resurgence of the old Google, actually giving a f about software, security and the end user. iPhone 17 has it now. maybe Google's work here is done https://www.reddit.com/r/apple/comments/1ndcrug/iphone_17_in...

Noaidi

A company making multi billions of dollars in profit still looking to save money selling their flagship phone?

hk1337

So, where does the restriction for side loading apps live, on the device or the OS? Curious about getting the Pixel 11 Pro if/when I can install GrapheneOS.

rkozik1989

Phones 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 it has to be stored somewhere before it gets encrypted, so assuming graphene OS doesn't handle both functions its not a perfectly closed loop system.

colincowardly

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.

protimewaster

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?

chasil

"Aside from MTE, Google downgraded the Pixel 11 series GPU compared to the Pixel 10 series in addition to reducing RAM for base Pro models." I will make a note not to buy this model. Is this the worst quality control lapse since the Huawei Nexus core failures?

iamnothere

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

moonshot5

AOSP eng here; I don't interact with Graphene or any of their folks at all; I'm just a distant observer like most folks here. Still, I can't help but think that Graphene seems to want to complain about everything and anything that doesn't fit their niche use case. (As much as it seems beloved here, people that flash custom Android OSs are the very definition of niche users.) My personal attitude to Graphene seems to get a bit more negative with each one of these "rants" and I doubt I'd go far out of my way to help them, even if I had exposure to them.

loufe

I am almost certainly going to live with whatever drawbacks in terms of camera quality, battery life, etc. Come with their Motorola phone when it's time to upgrade. MTE is such a non-negotiable for modern digital security on phones it's crazy Google would be so okay with this regression. What's especially stuck in my mind lately is how insecure basically all desktop OS' feel. In at the point of buying a second and third GPU for my desktop to run my email and browser in dedicated VMs because everything feels as watertight as a sieve. Qubes seems more and more appealing in a world where every open source software supply chain is under seige, corporate software underprioritizes security, and most sites will stop at almost nothing to surveil you. I truly lament this new reality where MY computers I PURCHASED feel to use like I'm reaching blind into a paper bag filled with razor blades.

mmooss

My strong instinct is that GrapheneOS's plan could be problematic: Generally, do not to invest in features that the upstream vendor isn't fully committed to. It might work today, but tomorrow or next year, etc., it might not. They might even deploy other things that are incompatible or do other things that assume the feature is disabled. In fact, plans to do those things might be the reason they disabled MTE. Also, never support products or projects that won't work well. When someone's Pixel 11 is slow, they will think and post that 'GrapheneOS is slow'. Blaming Google will not be very credible and will look like you're just trying to duck responsibility. Your brand's name goes whatever you release; people will associate their experience with GrapheneOS (also because GOS is the new, unconventional thing; Google is the established norm); if their experience is bad, they will associate it with GOS.

drabbiticus

12 hours before this was posted to HN: https://grapheneos.social/@GrapheneOS/117198980596943121 GrapheneOS: "Multiple Google engineers we've contacted have said they aren't able to give us any information about this so we're left doing reverse engineering and relying on leaks. The leaks do not seem reliable and do not match what we see. Our concern is that MTE may actually be broken due to CPU errata."

bushwart

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

eigenform

> It's possible to enable reserving the tag memory for MTE via `fastboot oem mte on`, boot a non-stock kernel ignoring arm64.nomte and use MTE. What I'd like to know is, is it not sufficient to just check the feature bits in ID_AA64PFR1_EL1? (Isn't this the first thing you'd try when trying to determine if the hardware supports some feature?) If they were making the determination solely based on the fact that `arm64.nomte` is being passed to the kernel (or based on what features are exposed by kernel interfaces), it may have been better to say "MTE is seemingly disabled in the current Android release" rather than claiming that it's simply not present in hardware. If you're asking the Linux kernel about hardware features, maybe it takes cmdline arguments into account when presenting that info to userspace. The TRM[^1] mentions that some of the feature bits depend on BROADCASTMTE (presumably some CPU input pin), but maybe that signal isn't constant and is allowed to change based on what happens in firmware/the bootloader? Also, why the claim about the lack of hardware acceleration for MTE in the caches, is there evidence for that, or is this also a misunderstanding? I think it's reasonable to assume that the perf impact of MTE is non-negligible (on cores in older Pixel devices[^2], MTE apparently suffers from the fact that checked stores are serializing!), but it's entirely possible that this does not follow from some physical design concession when implementing the SoC. The characterization of all this as some kind of cost-cutting measure is not necessarily accurate. [^1]: https://support.arm.com/documentation/108014/0101/?lang=en [^2]: https://arxiv.org/pdf/2601.11786