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