We have a partial port of GrapheneOS to the Pixel 11 series after a week of work on it. We're unable to complete the port due to lack of support for ARM hardware memory tagging in software, firmware and near certainly hardware. It appears Google cut an important security feature to save money.
My understanding is that while the older Pixel phones had MTE capability, it was off by default and could only be enabled under the dev settings. Google did not enable it by default because Android depends heavily on vendor board support packages, proprietary SOC drivers, and HAL modules. Google felt that driver code quality from 3rd-parties is not clean enough to enable kernel-level MTE without risking bootloops and spontaneous reboots. Even worse for C++ apps, which often read slightly past their allocated memory blocks.
Instead, Google rewrote critical core Android system daemons using Rust. Like the keystore, Bluetooth stack, DNS resolver, and others. I believe using Rust essentially makes MTE unnecessary.
Also full synchronous MTE mode has high CPU/memory bus penalties (could be 5-10% under heavy memory loads).
Google probably decided that since hardly anyone used MTE anyway on earlier Pixel devices, they could use the space in the chip for other uses.
The point is that the post makes it sound like using a Pixel 11 under Android results in less security than before, but for most people there is no change since they never used MTE anyway.
The point is that the post makes it sound like using a Pixel 11 under Android results in less security than before, but for most people there is no change since they never used MTE anyway.
That’s not what they’re saying. They’re saying Graphene without MTE is less secure, which isn’t something they want.
Which you can read from their post here
We strongly recommend against buying Pixel 11 devices. Pixel 8, 9 and 10 have much better overall security for GrapheneOS. Pixel 10 is cheaper with similar hardware and MTE. Pixel 11’s Titan M3 should improve BFU security for users without a strong passphrase, but losing MTE craters AFU security.
They’re saying Graphene without MTE is less secure, which isn’t something they want.
Well they’re inevitably backing into a dead-end. MTE is obviously off the table now which means eventually they’ll have no hardware fitting to their super-exacting demands. Motorola might come through, or not.
I hate being a conspiracy theorist but honestly sometimes the way Graphene clings to Pixels feels like a Google scheme to boost their pathetic Pixel market share.
It’s not an on/off kind of thing, MTE is a set of ARM extensions. Either the api to use them is clearly documented or, as in the pixel 11’s case, Google started to not document their implementation.
We know this matches their plan to obscure the AOSP code to eventually lock out anyone else from using their base.
GOS is not in a position to reverse-engineer api calls on what was formally documented hardware.
Instead, Google rewrote critical core Android system daemons using Rust. Like the keystore, Bluetooth stack, DNS resolver, and others. I believe using Rust essentially makes MTE unnecessary.
No. Rust being “memory safe” doesn’t mean rust apps can’t abuse speculation or buffer under/overruns.
The point is that the post makes it sound like using a Pixel 11 under Android results in less security than before, but for most people there is no change since they never used MTE anyway.
Read the BlueSky posts, Google didn’t force app devs to opt into MTE, so no one did.
Google probably decided that since hardly anyone used MTE anyway on earlier Pixel devices, they could use the space in the chip for other uses.
“Space in the chips”? Again, see the Bluesky posts.
Google is very clearly shifting over to a completely walled garden, because, same as Apple, it isn’t about the hardware performance and capabilities, it’s about control.
Yeah, enabling a bootctl flag is doable in any android version, it’s a prop available since Android 7. Again, it’s undocumented APIs at fault for the MTE not working in the Pixel 11.
My understanding is that while the older Pixel phones had MTE capability, it was off by default and could only be enabled under the dev settings. Google did not enable it by default because Android depends heavily on vendor board support packages, proprietary SOC drivers, and HAL modules. Google felt that driver code quality from 3rd-parties is not clean enough to enable kernel-level MTE without risking bootloops and spontaneous reboots. Even worse for C++ apps, which often read slightly past their allocated memory blocks.
Instead, Google rewrote critical core Android system daemons using Rust. Like the keystore, Bluetooth stack, DNS resolver, and others. I believe using Rust essentially makes MTE unnecessary.
Also full synchronous MTE mode has high CPU/memory bus penalties (could be 5-10% under heavy memory loads).
Google probably decided that since hardly anyone used MTE anyway on earlier Pixel devices, they could use the space in the chip for other uses.
The point is that the post makes it sound like using a Pixel 11 under Android results in less security than before, but for most people there is no change since they never used MTE anyway.
I think you misunderstand what is being said.
That’s not what they’re saying. They’re saying Graphene without MTE is less secure, which isn’t something they want.
Which you can read from their post here
Well they’re inevitably backing into a dead-end. MTE is obviously off the table now which means eventually they’ll have no hardware fitting to their super-exacting demands. Motorola might come through, or not.
I hate being a conspiracy theorist but honestly sometimes the way Graphene clings to Pixels feels like a Google scheme to boost their pathetic Pixel market share.
It’s not an on/off kind of thing, MTE is a set of ARM extensions. Either the api to use them is clearly documented or, as in the pixel 11’s case, Google started to not document their implementation.
We know this matches their plan to obscure the AOSP code to eventually lock out anyone else from using their base.
GOS is not in a position to reverse-engineer api calls on what was formally documented hardware.
No. Rust being “memory safe” doesn’t mean rust apps can’t abuse speculation or buffer under/overruns.
Read the BlueSky posts, Google didn’t force app devs to opt into MTE, so no one did.
“Space in the chips”? Again, see the Bluesky posts.
Google is very clearly shifting over to a completely walled garden, because, same as Apple, it isn’t about the hardware performance and capabilities, it’s about control.
It’s an on/off kind of thing: https://outflux.net/blog/archives/2023/10/26/enable-mte-on-pixel-8/
https://developer.android.com/ndk/guides/arm-mte
Yeah, enabling a bootctl flag is doable in any android version, it’s a prop available since Android 7. Again, it’s undocumented APIs at fault for the MTE not working in the Pixel 11.