> 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.
No that’s really underselling AddressSanitizer. The hardware-based MTE has a fixed number of tags available. So there’s a 7% chance of not detecting an occurrence of a memory bug.
ASan doesn’t really have such a limitation. It also works well for stack memory in addition to heap memory. MTE doesn’t protect your stack allocated objects.
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.
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.
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.
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.
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.
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.
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.
> 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.
Thankfully the project doesn't care about your personal attitude. That "niche use case" literally saves lives in countries where saying the wrong thing can put you to death. Since when is calling something out a rant?
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?
For example, a user being able to inspect and edit the files written by an app, no matter where or how those files were written, would be an anti-spyware feature: you could better observe the behavior of a closed-source application.
Grapene opposes this feature because the app security model protects the app AGAINST the device user editing or reading protected files.
Graphene's philosophy is enforcing the Android security model. The Android security model gives guarantees to the app developer about how their app can behave, even where the device's owner wishes otherwise. See: Play Integrity.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
No, shared peripherals need to go through a central arbiter for access. In the case of things like storage the AP's OS, eg android, provides that roll. This is also true for the OS that runs under the trustzone. Be careful about spreading rumors without validating them.
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.
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.
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."
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.
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.
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.
> 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
[1]: https://clang.llvm.org/docs/AddressSanitizer.html
ASan doesn’t really have such a limitation. It also works well for stack memory in addition to heap memory. MTE doesn’t protect your stack allocated objects.
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.
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?
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.
Vulnerabilities in the world’s most popular (by volume) mobile OS could provide a plausibly deniable global espionage backdoor.
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.
the fact that someone can say that post-Dual_EC_DRBG/project-rubicon/eternalblue/eternalromance exposure boggles the mind.
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.
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.
For example, a user being able to inspect and edit the files written by an app, no matter where or how those files were written, would be an anti-spyware feature: you could better observe the behavior of a closed-source application.
Grapene opposes this feature because the app security model protects the app AGAINST the device user editing or reading protected files.
Graphene's philosophy is enforcing the Android security model. The Android security model gives guarantees to the app developer about how their app can behave, even where the device's owner wishes otherwise. See: Play Integrity.
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?
Not saying whether it's a good thing or a bad thing, but just the nature of reality.
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.
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.
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.
I will make a note not to buy this model.
Is this the worst quality control lapse since the Huawei Nexus core failures?
Google Pixel has the marketshare it deserves.
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.
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.
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.
As currently written, one would take away an entirely different message from the headline.
iPhone 17 has it now. maybe Google's work here is done
https://www.reddit.com/r/apple/comments/1ndcrug/iphone_17_in...
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 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.
https://axis-intelligence.com/google-pixel-statistics/
They’re also strongly tied in with Google Fi which is almost certainly very profitable.
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."
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.
Why disabled? Well, its performance is apparently quite poor. But why?
...Apparently to save money.
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.
Is the thread wrong or did I misread it?
No evidence of this is presented.