4 ms·

GrapheneOS says Pixel 11 has MTE support after all

199 points by user_7832 24d ago

user_7832 24d ago
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.
- readthenotes1 24d ago
  The thread made it sound like it was more- that the actual release of pixel 11 did not have the firmware to support MTE, not that it was just disabled. Is the thread wrong or did I misread it?
  - user_7832 24d ago
    Nah sorry my bad. I mixed up "it's currently disabled" and "the hardware is there" into "it was earlier disabled".
- mmooss 24d ago
  [flagged]
  - preisschild 23d ago
    [flagged]
    - mmooss 23d ago
      [flagged]
- OneDeuxTriSeiGo 24d ago
  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.
chekibreki 24d ago
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 https://developer.android.com/ndk/guides/arm-mte
- delta_p_delta_x 24d ago
  MTE is essentially hardware-accelerated AddressSanitiser[1]. [1]: https://clang.llvm.org/docs/AddressSanitizer.html https://clang.llvm.org/docs/AddressSanitizer.html
  - wat10000 24d ago
    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.
    - timschmidt 24d ago
      4 bits per 16 bytes is ~ 1/4 the cost of ECC, which is possible to implement with just an extra cycle or two of latency in the memory controller. MTE seems similarly lightweight. Costs some transistors and a percent of a percent of power budget, but much like ECC it seems a fair bargain.
m00dy 24d ago
For those don't know you will either code in Rust or make sure MTE enabled.
greesil 24d ago
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_introduces_groundbreaking_new_memory/ https://www.reddit.com/r/apple/comments/1ndcrug/iphone_17_in...
Noaidi 24d ago
A company making multi billions of dollars in profit still looking to save money selling their flagship phone?
- jmm5 24d ago
  Google makes money, I'm not sure Pixel does.
  - ulfw 24d ago
    Zero chance the Pixel division is net positive
    - rootsudo 24d ago
      agreed h/w negative, but how far removed is pixel from android itself and then the ad tech platform, playstore, etc in general?
    - Grombobulous 24d ago
      I think there’s a very high chance it’s net positive. It’s growing quickly and approaching 10% marketshare for premium phones (the most profitable segment) in the US. https://axis-intelligence.com/google-pixel-statistics/ https://axis-intelligence.com/google-pixel-statistics/ They’re also strongly tied in with Google Fi which is almost certainly very profitable.
    - genxy 24d ago
      It is net positive for keeping folks in the Google Ads funnel. That is Androids purpose after all.
hk1337 24d ago
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.
- alpaca9 24d ago
  GrapheneOS themselves said it wasn't worth getting the 11 over the 10 on Twitter. It has a worse GPU and less RAM, and the increase in CPU speed is so negligible that often you end up with better performance using the previous generation. In addition, GrapheneOS isn't even available on 11 series devices yet.
  - hk1337 24d ago
    interesting. what about the side loading apps? I assume that's an OS and Graphene would likely allow it?
    - alpaca9 24d ago
      Sideloading has always been allowed, and that new "advanced flow" is something entirely decided by the OS so I don't think it has or will have any effect with GrapheneOS use. It's actually recommended to get least of your apps as possible via the play store and use 3rd party stores if you are going for maximum privacy or de-googling.
    - electric_mayhem 24d ago
      I’m in the process of switching from an iPhone to Graphene on a pixel 10 Pro. I can load apps from the web (disabled by default iirc), the local file system, a sandboxed instance of the Play store, Obtainium, f-droid, wherever. Took some getting used to, but it’s nice feeling like I actually control and can choose how my phone works.
      - alpaca9 24d ago
        I've done some research and am considering as well, though I might wait for the motorola phones to release. Have you encountered apps that didn't work? Like banking and stuff seems to break a lot of the time.
rkozik1989 24d ago
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.
- bramhaag 24d ago
  > 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? It shouldn't. As per https://grapheneos.org/faq#baseband-isolation https://grapheneos.org/faq#baseband-isolation: > The baseband is isolated on all of the officially supported devices. Memory access is partitioned by the IOMMU and limited to internal memory and memory shared by the driver implementations. The baseband on the officially supported devices with a Qualcomm SoC implements Wi-Fi and Bluetooth as internal sandboxed processes rather than having a separate baseband for those like earlier devices.
  - DANmode 24d ago
    IOMMU The way it should have been all along.
- ignoramous 24d ago
  > Phones typically have 2 operating systems A separate OS runs the security chip (like Titan). Another could be running in EL3 (Trusted Execution Environment), yet many could be running in Realms (mutually untrusted VMs). The later stage bootloaders and some firmware (ex: GPUs) themselves could be considered OSes in their own right.
  - w3ll_w3ll_w3ll 24d ago
    Also, the SIM card has its own operating system.
colincowardly 24d ago
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.
- megagpt1 24d ago
  There's no phone that isn't like that this year
  - mschild 24d ago
    Fairphone gen6+ (vs gen6) got an increase in ram from 8 to 12 and from Snapdragon 7s gen3 to gen4. MSRP only went from 599 to 649.
  - microtonal 24d ago
    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.
protimewaster 24d ago
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?
- worldsavior 24d ago
  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 24d ago
    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 24d ago
    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.
- Yokolos 24d ago
  I've read that there's a significant performance cost to MTE on Android (or on Tensor). It might just be that.
  - OneDeuxTriSeiGo 24d ago
chasil 24d ago
"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?
- infogulch 24d ago
  This isn't a quality control issue, but a beancounter-chooses-cheaper-parts issue.
  - chasil 24d ago
    One must believe that MTE was intended for use on this device, as it is present on everything down to the Pixel 6. Everything else is in the realm of bean counters, I would think.
- yaro330 24d ago
  The GPU claim is contradicted by pretty much every benchmark though.
iamnothere 24d ago
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.
- surajrmal 24d ago
  The perception that they are able to run rings around Google is not necessarily an accurate one. There are tradeoffs in any engineering situation and GrapheneOS devs make different ones based on different requirements. Google is one of the reasons MTE even exists. I don't think GrapheneOS devs would be capable of helping push forward that technology in the same capacity.
  - iamnothere 24d ago
    Fair, and also Google is not a monolith. I’m sure that their own security experts who helped push things like MTE are also confused and frustrated by the lack of internal adoption. A lot of heavy lifting is involved at the lower levels of security and Graphene doesn’t have to deal with this work, generally. I guess my surprise comes at the “fit and finish” stage where Google regularly seems to be lacking.
  - abdullahkhalids 24d ago
    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?
    - izacus 24d ago
      Actually functionality, stability of apps and features people use.
      - deleted 24d ago
        [deleted]
moonshot5 24d ago
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.
- WarmWash 24d ago
  When you are a minority you have to be incredibly loud for any chance to sway things your way. Not saying whether it's a good thing or a bad thing, but just the nature of reality.
  - riedel 24d ago
    [flagged]
- iamnothere 24d ago
  Security shouldn’t be a niche use case. There’s a constant trickle of CVEs, and spyware vendors are known to abuse these exploits in their software. All this on devices that are reachable in the US through a text or MMS, sent to an easily located 10 digit number that isn’t easily changed. These are devices that people now use for all kinds of sensitive tasks! Security should be the number one priority, frankly. Graphene has shown that this is possible, and they have tried multiple times to get Google to integrate their work.
- Iolaum 24d ago
  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?
  - 24d ago
loufe 24d ago
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.
- deleted 24d ago
  [deleted]
- rustcleaner 24d ago
  >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 made the same observations and conclusions as you, but a few years ago. I have been daily driving Qubes OS exclusively since on my Thinkpads. If you haven't started to yet, I implore you to consider the following when buying a system for Qubes: mid-line CPU with plenty of PCs (turn off the ECs), As much RAM as you can afford (seriously, budgetmaxxx on RAM), dedicated secondary GPU with the minimum specs you need is a must for inference (may have to widen the budget a little bit after budgetmaxxing RAM). Expect to not game on the platform. I have not tried this but if you can't cut the digital crack-cocaine habit then it may be possible to set up a gaming qube which takes the dGPU passed through: get a monitor + second USB keyboard & mouse, plug the monitor into the dGPU's HDMI ports, and pass through the secondary peripherals. Digital crack-cocai... err games... don't like having their frames pushed over X11 forwarding even if the dGPU is passed through, so you will need the monitor; the secondary input devices are so the mouse and keyboard inputs don't leave the gaming qube.
mmooss 24d ago
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.
- scheeseman486 24d ago
  Their plan is to seemingly comprehensively test MTE on the Pixel 11 to see if it's usable for them. I'm not sure how that's "problematic", in fact it seems like it's exactly what they should be doing. Their real focus is on their Motorola partnership, anyway.
- preisschild 23d ago
  GrapheneOS is a non-profit, publicly naming the actual issues is the only thing they can do to make Google fix those issues. And it is clear that security/privacy is their first priority, not "brand image"
  - mmooss 23d ago
    Some on HN defend everything GOS does (maybe not you, but there are some). Those people are hurting GOS. Good security engineering isn't sufficient: GOS could accomplish the security engineering by making an OS for themselves on a private git server and never distributing it. But if we want to help the public with security and privacy, then the outcome depends on GOS's brand image - perception drives public adoption, who will never read long posts on arcane engineering matters. It depends on GOS's relationship with Google and its individual engineers, a relationship in which Google and the engineers hold all the cards - they could choose to cut off GOS completely tomorrow at no cost to themselves. It's an engineer's fantasy that you can ignore those things and just do engineering; life just isn't like that. Doing that would imperil or greatly limit GOS, which hurts everyone.
drabbiticus 24d ago
12 hours before this was posted to HN: https://grapheneos.social/@GrapheneOS/117198980596943121 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 24d ago
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 24d ago
> 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 https://support.arm.com/documentation/108014/0101/?lang=en [^2]: https://arxiv.org/pdf/2601.11786 https://arxiv.org/pdf/2601.11786
- yaro330 24d ago
  A "Google bad" essay gets a lot more clicks.
- yxuehr 23d ago
  ID_AA64PFR1_EL1 was discussed five days ago https://discuss.grapheneos.org/d/41564-pixel-11-doesnt-meet-the-grapheneos-security-standards-and-may-be-skipped/40 https://discuss.grapheneos.org/d/41564-pixel-11-doesnt-meet-...
  - eigenform 23d ago
    Fascinating, thank you. It seems strange that the C1-Pro/C1-Ultra TRM mention that ID_AA64PFR1_EL1[11:8] should still be non-zero even when BROADCASTMTE is low. edit: Oh, I guess Linux does emulate the feature registers, doh. Since that user is booting with arm64.nomte, the kernel is changing those feature bits to zero! This probably explains the confusion here about hardware support: in Linux userspace, you still trap for system register reads, and this is just abstracted away from you... https://github.com/torvalds/linux/blob/841e384b841a3d89c50b4b2d6c5bb6abab1a7e39/arch/arm64/kernel/pi/idreg-override.c#L257 https://github.com/torvalds/linux/blob/841e384b841a3d89c50b4...
nunobrito 23d ago
[flagged]
- jasonvorhe 23d ago
  Weird how reports about GrapheneOS always come with some overtly generalized FUD that add nothing of value to the topic at hand.
massimodeluisa 23d ago
[dead]

199 points by user_7832 24d ago

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.

readthenotes1 24d ago
The thread made it sound like it was more- that the actual release of pixel 11 did not have the firmware to support MTE, not that it was just disabled. Is the thread wrong or did I misread it?
- user_7832 24d ago
  Nah sorry my bad. I mixed up "it's currently disabled" and "the hardware is there" into "it was earlier disabled".
mmooss 24d ago
[flagged]
- preisschild 23d ago
  [flagged]
  - mmooss 23d ago
    [flagged]
OneDeuxTriSeiGo 24d ago
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.

chekibreki 24d ago

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

delta_p_delta_x 24d ago
MTE is essentially hardware-accelerated AddressSanitiser[1]. [1]: https://clang.llvm.org/docs/AddressSanitizer.html https://clang.llvm.org/docs/AddressSanitizer.html
- wat10000 24d ago
  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.
  - timschmidt 24d ago
    4 bits per 16 bytes is ~ 1/4 the cost of ECC, which is possible to implement with just an extra cycle or two of latency in the memory controller. MTE seems similarly lightweight. Costs some transistors and a percent of a percent of power budget, but much like ECC it seems a fair bargain.

m00dy 24d ago

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

greesil 24d ago

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_introduces_groundbreaking_new_memory/ https://www.reddit.com/r/apple/comments/1ndcrug/iphone_17_in...

Noaidi 24d ago

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

jmm5 24d ago
Google makes money, I'm not sure Pixel does.
- ulfw 24d ago
  Zero chance the Pixel division is net positive
  - rootsudo 24d ago
    agreed h/w negative, but how far removed is pixel from android itself and then the ad tech platform, playstore, etc in general?
  - Grombobulous 24d ago
    I think there’s a very high chance it’s net positive. It’s growing quickly and approaching 10% marketshare for premium phones (the most profitable segment) in the US. https://axis-intelligence.com/google-pixel-statistics/ https://axis-intelligence.com/google-pixel-statistics/ They’re also strongly tied in with Google Fi which is almost certainly very profitable.
  - genxy 24d ago
    It is net positive for keeping folks in the Google Ads funnel. That is Androids purpose after all.

hk1337 24d ago

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.

alpaca9 24d ago
GrapheneOS themselves said it wasn't worth getting the 11 over the 10 on Twitter. It has a worse GPU and less RAM, and the increase in CPU speed is so negligible that often you end up with better performance using the previous generation. In addition, GrapheneOS isn't even available on 11 series devices yet.
- hk1337 24d ago
  interesting. what about the side loading apps? I assume that's an OS and Graphene would likely allow it?
  - alpaca9 24d ago
    Sideloading has always been allowed, and that new "advanced flow" is something entirely decided by the OS so I don't think it has or will have any effect with GrapheneOS use. It's actually recommended to get least of your apps as possible via the play store and use 3rd party stores if you are going for maximum privacy or de-googling.
  - electric_mayhem 24d ago
    I’m in the process of switching from an iPhone to Graphene on a pixel 10 Pro. I can load apps from the web (disabled by default iirc), the local file system, a sandboxed instance of the Play store, Obtainium, f-droid, wherever. Took some getting used to, but it’s nice feeling like I actually control and can choose how my phone works.
    - alpaca9 24d ago
      I've done some research and am considering as well, though I might wait for the motorola phones to release. Have you encountered apps that didn't work? Like banking and stuff seems to break a lot of the time.

rkozik1989 24d ago

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.

bramhaag 24d ago
> 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? It shouldn't. As per https://grapheneos.org/faq#baseband-isolation https://grapheneos.org/faq#baseband-isolation: > The baseband is isolated on all of the officially supported devices. Memory access is partitioned by the IOMMU and limited to internal memory and memory shared by the driver implementations. The baseband on the officially supported devices with a Qualcomm SoC implements Wi-Fi and Bluetooth as internal sandboxed processes rather than having a separate baseband for those like earlier devices.
- DANmode 24d ago
  IOMMU The way it should have been all along.
ignoramous 24d ago
> Phones typically have 2 operating systems A separate OS runs the security chip (like Titan). Another could be running in EL3 (Trusted Execution Environment), yet many could be running in Realms (mutually untrusted VMs). The later stage bootloaders and some firmware (ex: GPUs) themselves could be considered OSes in their own right.
- w3ll_w3ll_w3ll 24d ago
  Also, the SIM card has its own operating system.

colincowardly 24d ago

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.

megagpt1 24d ago
There's no phone that isn't like that this year
- mschild 24d ago
  Fairphone gen6+ (vs gen6) got an increase in ram from 8 to 12 and from Snapdragon 7s gen3 to gen4. MSRP only went from 599 to 649.
- microtonal 24d ago
  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.

protimewaster 24d ago

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?

worldsavior 24d ago
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 24d ago
  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 24d ago
  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.
Yokolos 24d ago
I've read that there's a significant performance cost to MTE on Android (or on Tensor). It might just be that.
- OneDeuxTriSeiGo 24d ago

chasil 24d ago

"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?

infogulch 24d ago
This isn't a quality control issue, but a beancounter-chooses-cheaper-parts issue.
- chasil 24d ago
  One must believe that MTE was intended for use on this device, as it is present on everything down to the Pixel 6. Everything else is in the realm of bean counters, I would think.
yaro330 24d ago
The GPU claim is contradicted by pretty much every benchmark though.

iamnothere 24d ago

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.

surajrmal 24d ago
The perception that they are able to run rings around Google is not necessarily an accurate one. There are tradeoffs in any engineering situation and GrapheneOS devs make different ones based on different requirements. Google is one of the reasons MTE even exists. I don't think GrapheneOS devs would be capable of helping push forward that technology in the same capacity.
- iamnothere 24d ago
  Fair, and also Google is not a monolith. I’m sure that their own security experts who helped push things like MTE are also confused and frustrated by the lack of internal adoption. A lot of heavy lifting is involved at the lower levels of security and Graphene doesn’t have to deal with this work, generally. I guess my surprise comes at the “fit and finish” stage where Google regularly seems to be lacking.
- abdullahkhalids 24d ago
  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?
  - izacus 24d ago
    Actually functionality, stability of apps and features people use.
    - deleted 24d ago
      [deleted]

moonshot5 24d ago

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.

WarmWash 24d ago
When you are a minority you have to be incredibly loud for any chance to sway things your way. Not saying whether it's a good thing or a bad thing, but just the nature of reality.
- riedel 24d ago
  [flagged]
iamnothere 24d ago
Security shouldn’t be a niche use case. There’s a constant trickle of CVEs, and spyware vendors are known to abuse these exploits in their software. All this on devices that are reachable in the US through a text or MMS, sent to an easily located 10 digit number that isn’t easily changed. These are devices that people now use for all kinds of sensitive tasks! Security should be the number one priority, frankly. Graphene has shown that this is possible, and they have tried multiple times to get Google to integrate their work.
Iolaum 24d ago
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?
- 24d ago

loufe 24d ago

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.

deleted 24d ago
[deleted]
rustcleaner 24d ago
>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 made the same observations and conclusions as you, but a few years ago. I have been daily driving Qubes OS exclusively since on my Thinkpads. If you haven't started to yet, I implore you to consider the following when buying a system for Qubes: mid-line CPU with plenty of PCs (turn off the ECs), As much RAM as you can afford (seriously, budgetmaxxx on RAM), dedicated secondary GPU with the minimum specs you need is a must for inference (may have to widen the budget a little bit after budgetmaxxing RAM). Expect to not game on the platform. I have not tried this but if you can't cut the digital crack-cocaine habit then it may be possible to set up a gaming qube which takes the dGPU passed through: get a monitor + second USB keyboard & mouse, plug the monitor into the dGPU's HDMI ports, and pass through the secondary peripherals. Digital crack-cocai... err games... don't like having their frames pushed over X11 forwarding even if the dGPU is passed through, so you will need the monitor; the secondary input devices are so the mouse and keyboard inputs don't leave the gaming qube.

mmooss 24d ago

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.

scheeseman486 24d ago
Their plan is to seemingly comprehensively test MTE on the Pixel 11 to see if it's usable for them. I'm not sure how that's "problematic", in fact it seems like it's exactly what they should be doing. Their real focus is on their Motorola partnership, anyway.
preisschild 23d ago
GrapheneOS is a non-profit, publicly naming the actual issues is the only thing they can do to make Google fix those issues. And it is clear that security/privacy is their first priority, not "brand image"
- mmooss 23d ago
  Some on HN defend everything GOS does (maybe not you, but there are some). Those people are hurting GOS. Good security engineering isn't sufficient: GOS could accomplish the security engineering by making an OS for themselves on a private git server and never distributing it. But if we want to help the public with security and privacy, then the outcome depends on GOS's brand image - perception drives public adoption, who will never read long posts on arcane engineering matters. It depends on GOS's relationship with Google and its individual engineers, a relationship in which Google and the engineers hold all the cards - they could choose to cut off GOS completely tomorrow at no cost to themselves. It's an engineer's fantasy that you can ignore those things and just do engineering; life just isn't like that. Doing that would imperil or greatly limit GOS, which hurts everyone.

drabbiticus 24d ago

12 hours before this was posted to HN: https://grapheneos.social/@GrapheneOS/117198980596943121 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 24d ago

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 24d ago

> 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 https://support.arm.com/documentation/108014/0101/?lang=en [^2]: https://arxiv.org/pdf/2601.11786 https://arxiv.org/pdf/2601.11786

yaro330 24d ago
A "Google bad" essay gets a lot more clicks.
yxuehr 23d ago
ID_AA64PFR1_EL1 was discussed five days ago https://discuss.grapheneos.org/d/41564-pixel-11-doesnt-meet-the-grapheneos-security-standards-and-may-be-skipped/40 https://discuss.grapheneos.org/d/41564-pixel-11-doesnt-meet-...
- eigenform 23d ago
  Fascinating, thank you. It seems strange that the C1-Pro/C1-Ultra TRM mention that ID_AA64PFR1_EL1[11:8] should still be non-zero even when BROADCASTMTE is low. edit: Oh, I guess Linux does emulate the feature registers, doh. Since that user is booting with arm64.nomte, the kernel is changing those feature bits to zero! This probably explains the confusion here about hardware support: in Linux userspace, you still trap for system register reads, and this is just abstracted away from you... https://github.com/torvalds/linux/blob/841e384b841a3d89c50b4b2d6c5bb6abab1a7e39/arch/arm64/kernel/pi/idreg-override.c#L257 https://github.com/torvalds/linux/blob/841e384b841a3d89c50b4...

nunobrito 23d ago

[flagged]

jasonvorhe 23d ago
Weird how reports about GrapheneOS always come with some overtly generalized FUD that add nothing of value to the topic at hand.

massimodeluisa 23d ago

[dead]