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?
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.
> 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.
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.
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?
> that Graphene seems to want to complain about everything and anything that doesn't fit their niche use case
What would you want them to complain about instead? Of course they'll complain about that, just like Googlers will complain about things affecting their stock price, no one is surprised that people care about stuff they're personally involved in, it makes a lot of sense.
Now if these complaints weren't accurate, then I'd walk with you and feel a bit more negative with each piece. But the ones I've looked into, have been spot on, so who cares if it's for their specific niche? I expect them to care about their niche, that's why those people all work together in that organization in the first place.
I personally would wish that the AOSP communities would work together. I would love to see some oft their work to also land on other devices even if that's not 100% secure without bootloader relocking. It sometimes seems to me that the perfect seems to be the enemy of the good sometimes. I still understand their sentiment and their goals. I hope that the Motorola thing takes off. Still think a crossover with true aftermarket roms would not hurt.
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? They don't need more stress in their day and wouldn't want to engage, with the promise of enjoying more of the same treatment. If it's consolation, much of their communication seems the same - it has nothing to do with AOSP or Google. :)
Communication is a challenging skill and not all good engineers are good at it. It's stressful to be in a role that demands lots communication if you feel you aren't good at it (I'm not speaking for GOS leaders - I don't know what they think).
Going out on a limb, hoping it helps - the most powerful single solution IME is compassion: Compassion toward yourself and toward others. They are engineers like you, trying to get through a stressful day like you, and they could use some pleasant interaction from someone who understands what it's like. You could use some of that too. Running GOS isn't easy, I'm sure.
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.
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.
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.
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.
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.
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."
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.
To start, stop using a browser to read your email. Use a mail client. Then you can block all network traffic for that dedicated email user, except to the mail server and ports.
EG bobemail user cannot connect to the net.
Now, 99.99% of webmail attacks fall flat or just can't call home.
Then, change the link open command to a bash script which does a sudo to a separate web user.
Now you've segregated mail and web.
For the web user, you can VM it. However, qemu lets you literally share a GPU with your VM for opengl. I've been using it for years. No second card needed. I use webgl stuff all the time.
Your "open link" bash scriot can ssh to the VM, and launch firefox with an url. The same way it would locally, without a VM.
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.
> 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 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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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?
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.
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
MTE is essentially hardware-accelerated AddressSanitiser[1].
[1]: https://clang.llvm.org/docs/AddressSanitizer.html
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.
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?
> that Graphene seems to want to complain about everything and anything that doesn't fit their niche use case
What would you want them to complain about instead? Of course they'll complain about that, just like Googlers will complain about things affecting their stock price, no one is surprised that people care about stuff they're personally involved in, it makes a lot of sense.
Now if these complaints weren't accurate, then I'd walk with you and feel a bit more negative with each piece. But the ones I've looked into, have been spot on, so who cares if it's for their specific niche? I expect them to care about their niche, that's why those people all work together in that organization in the first place.
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.
I personally would wish that the AOSP communities would work together. I would love to see some oft their work to also land on other devices even if that's not 100% secure without bootloader relocking. It sometimes seems to me that the perfect seems to be the enemy of the good sometimes. I still understand their sentiment and their goals. I hope that the Motorola thing takes off. Still think a crossover with true aftermarket roms would not hurt.
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? They don't need more stress in their day and wouldn't want to engage, with the promise of enjoying more of the same treatment. If it's consolation, much of their communication seems the same - it has nothing to do with AOSP or Google. :)
Communication is a challenging skill and not all good engineers are good at it. It's stressful to be in a role that demands lots communication if you feel you aren't good at it (I'm not speaking for GOS leaders - I don't know what they think).
Going out on a limb, hoping it helps - the most powerful single solution IME is compassion: Compassion toward yourself and toward others. They are engineers like you, trying to get through a stressful day like you, and they could use some pleasant interaction from someone who understands what it's like. You could use some of that too. Running GOS isn't easy, I'm sure.
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.
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.
Just to nitpick, the facilitation by AOSP & ARM is available so it is not about the OS but about Google as a Hardware manufacturer.
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.
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.
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.
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."
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.
To start, stop using a browser to read your email. Use a mail client. Then you can block all network traffic for that dedicated email user, except to the mail server and ports.
EG bobemail user cannot connect to the net.
Now, 99.99% of webmail attacks fall flat or just can't call home.
Then, change the link open command to a bash script which does a sudo to a separate web user.
Now you've segregated mail and web.
For the web user, you can VM it. However, qemu lets you literally share a GPU with your VM for opengl. I've been using it for years. No second card needed. I use webgl stuff all the time.
Your "open link" bash scriot can ssh to the VM, and launch firefox with an url. The same way it would locally, without a VM.
It's a very quick way to step up security nicely.
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.
> 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.
Also, the SIM card has its own operating system.
"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?
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...
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.
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.
interesting. what about the side loading apps? I assume that's an OS and Graphene would likely allow it?
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.
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.
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.
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.
For those don't know you will either code in Rust or make sure MTE enabled.
A company making multi billions of dollars in profit still looking to save money selling their flagship phone?
Google makes money, I'm not sure Pixel does.
Zero chance the Pixel division is net positive
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/
They’re also strongly tied in with Google Fi which is almost certainly very profitable.
agreed h/w negative, but how far removed is pixel from android itself and then the ad tech platform, playstore, etc in general?
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.
> Apparently to save money.
No evidence of this is presented.
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?
Nah sorry my bad. I mixed up "it's currently disabled" and "the hardware is there" into "it was earlier disabled".