GrapheneOS finds Bluetooth memory corruption via ARM MTE
grapheneos.social
grapheneos.social
I really want to see someone from the Pixel team justifying the decision here. I really wonder what the thought process is for someone to disable such a significant security feature for negligible performance gain.
They could enable it for the whole base OS and apps opting into it. They have already fixed nearly all the bugs uncovered in regular usage. They did nearly all the work but didn't take it over the finish line due to performance and memory/cache usage concerns. Their security engineers did their job already. They have very talented people working for them. Our ability to ship this feature before them is because the performance and memory concerns are not significant enough to matter to us. We're more than willing to lose 3.125% memory/cache and we accept the performance overhead of asymmetric MTE which is in the ballpark of a few percent overhead in most cases rather than near 0% like asynchronous MTE. There are cases where asymmetric MTE has a larger overhead than a few percent, but it's not common. Async mode is nearly free. MTE may not be as low overhead on future Pixels. It depends on them deciding to prioritize MTE performance in their future custom CPU design. If they do not ship it in production, it's unlikely that they'll prioritize the performance. The overhead may increase from 0% for async and a few percent for asymm to a far more significant cost.
The performance argument against MTE being deployed in production and against supporting MTE at all is the argument that's relevant. There is no other significant reason not to ship it for the base OS and enable it for all their own apps in their manifests. Getting it enabled for the whole app ecosystem is a much bigger problem requiring multiple steps: 1) broad availability of MTE capable devices for app developers, 2) making it opt-out instead of opt-in for a future target API level so developers get around a year and a half to either opt-out or deal with it, 3) removing the opt-out for a future target API level so that developers cannot simply opt-out. We know that part is hard. We know that part involves documentation, developer relations, concerns about giving app developers too much to deal with too quickly, etc. It isn't what we expect them to do short term. What we want them to do is enabling the near 0 overhead sync MTE for Pixels by default, with it used in the base OS and Google apps opting into it. They already did most of the work, even years earlier via HWAsan testing.
We don't expect them to enable asymmetric MTE or keep track of tags to provide more deterministic guarantees as we're doing. We understand they don't want to sacrifice 5% overall performance, and don't expect them to, but they could provide an opt-in for asymmetric mode + better deterministic guarantees. Google can could do it for Android 15 if they make the decision to do it now. A reasonable prediction is that in a couple years Apple ships MTE support in hardware with async mode by default and asymm in lockdown mode, and then Google does the same. They have a chance to be a leader on a hardware security feature far more valuable than the PAC feature where iOS is years ahead.
Most of the crashes were fixed via HWAsan before MTE existed in hardware. Their security people want MTE enabled in production. These issues were fixed before MTE and would have been fixed whether or not MTE was available in the standard ARMv9 cores/cache used by Pixels. MTE would likely already be enabled in production for the base OS (not user installed apps) if there weren't performance concerns. They clearly integrated it with that intention. We're more than capable of reading the commit messages and talking to engineers who worked on it along with other contacts there. They aren't keeping it a secret that there's a clear goal to enable MTE in production.
ARM provided MTE in their standard ARMv9 Cortex core designs. That's why MTE is available on the Pixel 8 and Pixel 8 Pro, because Tensor currently uses the standard core/cache designs. That's why MTE is not available for Snapdragon, and it's why it is theoretically available for MediaTek and Exynos.
The current availability of a high performance MTE implementation doesn't mean Google is highly committed to it. Pixels will be moving from standard Cortex core designs to their own core designs. There's an open question about whether MTE will be supported in the same way it is now. You're assuming that they're heavily committed to it and going to keep providing an extremely low overhead implementation. We have concrete reasons to be concerned.
We're only proposing enabling it for the base OS and user installed apps opting into it. Google has already fixed nearly all the crashes due to testing with HWAsan and MTE. They don't test enough with real world usage yet because they haven't deployed it for all the dogfooding devices. To do that, they need to set up enabling it for the base OS without enabling it for all user installed apps because that's not currently very practical. Google has already done most of the work for enabling it for the base OS, not us. We have to fix some bugs, but they're almost all regressions which don't live past the next quarterly releases since they do find and fix them. Google is 100% capable of enabling MTE for the Pixel stock OS within the base OS without a significant increase to crashes for users. In fact, it will significantly decrease user-facing crashes once it matures. It will result in so many memory corruption bugs being fixed. Testing internally with MTE doesn't do the same thing as deploying it to production in terms of bug fixing and also doesn't provide hardening against the bugs not occurring during regular usage.
I'm always looking for ways to implement cool stuff and make things in android better, but it's a little myopic to ignore the larger OEM ecosystem when complaining about specific feature roll outs.
I highly doubt the reason this isn't enabled is the 3% memory/cache usage, and there's some other consideration that's informing the decision.
AOSP also only directly supports the phones/tablets we support. We were only talking about 2 of the devices supported by AOSP. Pixels enabling MTE is not connected to other devices. App compatibility is also not an issue because it can be enabled for the base OS with user installed apps excluded until they opt into it. It can be made opt-out in a future target API level (Android 15) and then the opt-out can be removed in the next target API level. This is entirely doable.
> I'm always looking for ways to implement cool stuff and make things in android better, but it's a little myopic to ignore the larger OEM ecosystem when complaining about specific feature roll outs.
We're not ignoring it. We're talking about the Pixel 8, Pixel 8 Pro and future Pixels. It's a request for Pixels to enable it, not AOSP to enable it for all devices.
> I highly doubt the reason this isn't enabled is the 3% memory/cache usage, and there's some other consideration that's informing the decision.
Performance and memory usage are definitely the only blocker to enabling it for the base OS. It would already be enabled if the security team was in charge of these decisions. It's not enabled because they likely have to prove it's fast enough. Our specific recommendation was enabling it in asynchronous mode for all cores for the base OS and user installed apps explicitly opting into it. We do not think it's a good idea to start automatically opting apps into using it until more Android devices support it. Google could require that ARMv9 devices support MTE as a developer option for Android 15 onwards in the CDD in order to make sure developers have it available for testing. App developers can't be expected to have a Pixel so it's unrealistic to have it forced on app developers via target API level until more devs have devices available to test it. We understand all that and what we are pushing for takes that into account.
Longer answer:
Google folks were responsible for pushing on Hardware MTE in the first place - It originally came from the folks who also did work on ASAN, syzkaller, etc. They are not in Android, but it was done with the help and support of folks in Android. That's the Google side, it was obviously a partnership with ARM/etc as well.
I was the director for the teams that created/pushed on it, way back when - this was years ago at this point because of the lead times on a hardware/architecture feature like this.
So i'm very familiar with the tradeoffs.
It is more than just the memory usage or cache. The post is correct that it was designed to be able to be enabled/disabled dynamically, and needed to have expected perf cost ~0, but the main use case at the time was sampling based bug finding.
That is, if you turn MTE on (whether servers, phones, whatever) for 1% of the time for your entire fleet, and you have a large enough fleet, you will find basically all bugs very quickly. You can do this during dogfooding, etc.
Put another way - the goal was to make it possible to use have the equivalent of ASAN be flipped on and off when you want it.
Keeping it on all the time as a security mitigation was a secondary possibility, and has issues besides memory overhead.
For example, you will suddenly cause tons of user-visible crashes. But not even consistently. You will crash on phones with MTE, but not without it (which is most of them).
This is probably not the experience you want for a user.
For a developer, you would now have to force everyone to test on MTE enabled phones when there are ~1 of them. This is not likely to make developers happy.
Are there security exploits it will mitigate? Yes, they will crash instead of be exploitable. Are there harmless bugs it will catch? Yes.
But keep in mind what i said at the beginning - i would not assume they don't use it.
I would instead assume they don't necessarily use it in production on all the time.
Anyone who has experience on hardware feature bringup of this kind will tell you the fact that they can boot and run the system and only when they do this one thing does it crash under MTE is actually a very good sign they do use it.
Otherwise it would have probably crashed a million times :)
As an aside - It's also not obvious it's the best choice for run-time mitigation.
We know they're actively testing HWASan and MTE builds, but not with enough real world usage. If they tested it a lot on actual devices used by Google employees, they'd have fixed this Bluetooth LE audio issue before the release.
>As an aside - It's also not obvious it's the best choice for run-time mitigation.
What are some of the current contenders/arguments?
Edit: Nevermind, I seen it's only for Pixel 8 phones: https://news.ycombinator.com/item?id=38125379
They provide a nicer MTE implementation as part of hardened_malloc which uses the standard random tags with a dedicated free tag but adds dynamic exclusion of previous tag and current (or previous) adjacent tags. We also fixed Chromium's integration and will improve PartitionAlloc.
They also use it for their browser too using PartitionAlloc. Other Chromium-based browsers including Chrome don't use MTE since they don't really use the system allocators and have PartitionAlloc MTE disabled.
They are also continuing work on integrating more ARMv9 security features. MTE having the highest impact and being the most interesting of these features, but they're expanding usage of PAC and BTI. Android uses Clang's type-based CFI but not everywhere so BTI is still useful.
We provided a user facing crash report system for memory corruption detected by MTE. MTE has no false positives. We strongly recommend users use the feature we provided for copying the crash report to report these bugs to app developers. App developers can replicate many of the bugs reported this way using either MTE on a Pixel 8 or a smaller subset by building their app with HWASan support.
Since many apps have latent memory corruption, we only enable it for the base OS, base OS apps and known compatible user installed apps by default. Users can opt-in to heap MTE for all user installed apps via Settings > Security and can then opt-out for apps with memory corruption occurring during regular use. Over time, we plan to add more apps like Signal/Molly known to be compatible to it into our app compatibility database so that it's force enabled for them by default without users enabling it in Settings > Security. The option to opt-out is only available for apps not known to be compatible with it, which is part of dealing with the issue of users potentially allowing it after an exploit attempt.
We're trying to convince Google to at least enable asynchronous MTE by default for the stock Pixel OS with user installed apps excluded from it unless they opt-in to it. The memory overhead is 3.125% and asynchronous heap MTE is near 0 performance overhead. Asymmetric heap MTE provides much better security but is more comparable to the overhead of a feature like legacy stack smashing protection. Stack MTE adds more overhead but SSP could be disabled to partly make up for it and deterministic protection of stack spills, return value, etc. can be provided through MTE instead since by not being tagged they have the 0 tag and everything tagged will be a random non-0 tag.
GrapheneOS uses our own implementation of hardware memory tagging for hardened_malloc with stronger security properties. In order to enable it by default for the base OS, we had to fix or work around various issues including this one. We use MTE in asymmetric mode across all cores rather than using asynchronous MTE for the main cores. Asymmetric mode is asynchronous for writes but synchronous for reads, which blocks exploitation properly rather than having a window of opportunity to succeed with exploitation. It gets checked on system calls and io_uring (another potential source of bypasses) is only available to 2 core system processes on Android via SELinux restrictions (fastbootd which is only used during installation and snapuserd used by the core OS after applying updates).
GrapheneOS always uses heap MTE for the base OS and apps known to be compatible with it. For user installed apps which are not in our compatibility database and which do not mark themselves as compatible, we provide a per-app toggle for enable MTE. Users can also toggle on using MTE by default for user installed apps which may not be compatible and can instead opt-out for incompatible apps. In order for this to be usable, we had to implement a user-facing crash reporting system. We did this in a way that users can easily copy a useful crash report to provide developers.
https://youtu.be/KmFVPyHyfqQ / https://ghostarchive.org/varchive/KmFVPyHyfqQ
https://youtu.be/9wRT2hNwbkA / https://ghostarchive.org/varchive/9wRT2hNwbkA
So they support it even a bit longer than google officially does.
If a critical vulnerability is found in a Qualcomm modem, wifi, or bluetooth firmware, there may be scenarios where this cannot be fixed at the OS level.
Android doesn't have a separate vendor security patch level. It has a single security patch level covering all of the Android security bulletin and OEM security bulletin patches. Most alternate operating systems set an inaccurate Android security patch level where they redefine it to mean AOSP patches. They added a separate Vendor security patch level to put the real patch level. The whole thing is strange because the whole point is having a simple overall patch level and being honest about it. The standard Android security patch level only includes Critical/High severity vulnerabilities now, not Moderate/Low severity, and it doesn't include a lot of things that are deemed optional or out-of-scope. Can see this by looking at the Pixel bulletins where there are tons of patches that are clearly generic AOSP patches for all devices and patches tied to components like the Exynos radio clearly used by other devices. Android Security Bulletin (ASB) and the patch level derived from it does cover a LOT of drivers/firmware, but far from all or even most.
The missing patches for end-of-life devices include a lot more than outdated firmware in practice since drivers stop being updated and maintenance doesn't get taken over by others. The kernel drivers are open source but it doesn't mean someone takes over maintaining them. It's often mistaken as having all patches to open source code and missing patches to proprietary code but that's not accurate since updating AOSP is not updating all open source code. Lots of device specific code including even large parts of firmware is open source. As an example, Pixels use Trusty OS for the TEE and secure core, littlekernel for the boot chain firmware, etc. Security patches to those open source projects are security patches requiring new signed firmware updates to be released despite being open source patches.
I do wonder what I am seeing on Lineage with an older device, where the OS security is current, but the vendor security is long out of date.
I had no idea that a library was presented by the bootloader (AVB).
Interesting reading.
Our hardware security requirements are listed at https://grapheneos.org/faq#future-devices. Pixels are the only devices providing the requirements we set for updates and the list of security features. They also provide proper alternate OS support where all those security features work correctly. Samsung has most of the expected features and provides a similar length of support and number of major yearly updates but is missing the proper alternate OS support, MTE and the monthly/quarterly updates.
Each month, there's a new Android release which are distinct from the partial backporting of privacy/security patches to older versions. It's not monthly security releases but rather monthly performance/security/feature releases with separate backports of all Critical/High severity patches to older versions. Android 14 and Android 14 QPR1 are older versions of Android, and there are security backports to Android 14 separate from the monthly releases. This is currently fairly exclusive to Pixels. Samsung is getting much better at doing the security backports and are reducing delays for major updates but they're still acting as if the monthly/quarterly releases don't exist.
Not everybody has the same security needs, I often gift my older phones to my family members and if I have the choice to leave them on a fully unpatched device vs a GrapheneOS that is a "best effort" patch I will happily choose GrapheneOS.
I am super glad for all the work you guys do in any case, you can only love from me and I am honestly not buying an phone that doesn't support GrapheneOS at this point.
We're very happy that support increased to 5 years for 6th generation devices and then 7 years for 8th generation devices because we will no longer feel the need to do harm reduction via extended support. It will save us a huge amount of time and concern about people continuing to use these insecure devices.
7 years for a phone that's used as a main personal phone is a long time. Most people aren't going to use it that long, particularly a flagship phone. It mostly benefits people buying it used. It would be quite strange to buy a Pixel 8 Pro and use it for all 7 years. The audience for using a phone that long is probably going to buy a cheaper phone. The main benefit is to someone buying a used device where it still has 4 years of support after someone replaces it after 3 years. We aren't a fan of people unable to afford new phones getting insecure used devices. This is a big step towards that not happening anymore. 7 years is longer than iPhones have been getting full support updating them to the new major OS releases with full security patches.
We worry a lot that we're encouraging people to keep using insecure devices by providing extended support but we feel we have to provide it with how many people are clearly still using the end-of-life devices. However, how much of the amount of people still using them is because they think they are fine due to continued GrapheneOS support? This bothers us.
As an alternative to replaceable batteries you could consider installing something like acc[1] to mitigate stress on your battery. My phone is 7 years old and the original battery still holds a charge like the day I bought it.
[0]: https://github.com/uBlockOrigin/uBlock-issues/discussions/22...
Our specific hardware requirements are listed at https://grapheneos.org/faq#future-devices. It's a very concrete list of requirements there rather than subjective things. You can select a device and go through the list checking what's supported, and it will make sense why we can't support it. It's far more than a few minor things missing on other devices. They're missing basic things required to have features like encryption working for most users. Most Android devices don't meet bare minimum security requirements. At least 2 of the features we list exist because of us pushing for them from Pixels. There's another feature shipping around April which we proposed, and it will definitely be added to the list right away because it's critically important for defending against forensic data extraction before the device gets data back at rest via our auto-reboot timer after locking.
> I still wish they'd release "GrapheneOS Minus" (in the vein of uBlock Origin Minus[0]) so a much larger audience could have 95% of the security benefits they'd have on Pixel hardware.
It would not be anywhere close to providing 95% of the security benefits. In fact, it would largely be reducing security as the baseline without the hardware having proper alternate OS support. If you unlock a Samsung phone, the next closest to meeting our requirements, you cripple the device's security. Many of the hardware security features aren't available for an alternate OS and some even remain permanently disabled if you lock with the stock OS again. How can we support a device like that? Many of these hardware security features are what the OS security features are built on. Our work on integrating MTE into hardened_malloc and turning Android and Chromium's MTE support into something that can be used in production doesn't do any good on a device with no MTE, but this applies far beyond MTE. MTE alone is a significant part of the exploit protection advantages we're providing and is going to grow as we do more MTE integration work including potentially getting stack allocation MTE enabled in a way that doesn't break app compatibility (stack scanning by GC, etc.).
Recommend reading through our security requirement list. It will make much more sense. It's not an exhaustive list of what we require but is what we were able to turn into clear concrete requirements which should be expected for all reasonably secure mobile devices.
Never heard of Google making installation of non genuine components hard the way Apple does.
*If your hands are too clumsy to reconnect battery wires when swapping batteries, get a swiss knife.
Look at this: https://www.ifixit.com/Guide/Google+Pixel+8+Battery+Replacem...
That's not "swiss knife" replacement.
Now I concur with the original poster in his lament on lack of new and fancy, yet fully owned by the user, phones that can cooperate with Graphene OS
> I still wish they'd release "GrapheneOS Minus" (in the vein of uBlock Origin Minus[0]) so a much larger audience could have 95% of the security benefits they'd have on Pixel hardware.
It would not be anywhere close to providing 95% of the security benefits. In fact, it would largely be reducing security as the baseline without the hardware having proper alternate OS support. If you unlock a Samsung phone, the next closest to meeting our requirements, you cripple the device's security. Many of the hardware security features aren't available for an alternate OS and some even remain permanently disabled if you lock with the stock OS again. How can we support a device like that? Many of these hardware security features are what the OS security features are built on. Our work on integrating MTE into hardened_malloc and turning Android and Chromium's MTE support into something that can be used in production doesn't do any good on a device with no MTE, but this applies far beyond MTE. MTE alone is a significant part of the exploit protection advantages we're providing and is going to grow as we do more MTE integration work including potentially getting stack allocation MTE enabled in a way that doesn't break app compatibility (stack scanning by GC, etc.).
Recommend reading through our security requirement list. It will make much more sense. It's not an exhaustive list of what we require but is what we were able to turn into clear concrete requirements which should be expected for all reasonably secure mobile devices.
https://www.ifixit.com/repairability/smartphone-scores
> The battery is stubbornly glued down, and the soldered charge port can’t be easily replaced.
You have to take a heat gun to your phone to soften the glue to get the old battery out. Too little heat, the battery won't budge. Too much heat, you damage your screen or worse, ignite your battery. Good luck.
ARM did the work of designing it and integrating it into their standard ARM Cortex core/cache designs. Google/Samsung did the work of preserving standard ARM functionality, unlike Qualcomm which currently loses it. Google/Samsung also had to integrate it into the boot chain. They'd already previously done most of the bug fixing work via testing with HWASan. It is certainly true that Google paved the way to use MTE with HWASan and did a lot of the bug fixing work in the OS but external security researchers did a lot of this work too.
Nope, unless you can fore your phone to only charge to below 80% they strain the battery just as much if not more by keeping them at 100% all the time.
VoLTE in general is quite the trash fire.
https://grapheneos.org/features
CalyxOS is not a hardened OS. It greatly reduces security vs. AOSP via added attack surface, rolled back security and slow patches. CalyxOS does not have features like this. It does the opposite of this.
Compatibility with Android apps on GrapheneOS is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer:
https://grapheneos.org/usage#sandboxed-google-play
Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the problematic microG approach.
https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.
https://privsec.dev/posts/android/choosing-your-android-base... is an article with more long form comparisons between OSes.
GrapheneOS provides much better privacy than CalyxOS including features like Contact Scopes, Storage Scopes, per-app Sensors toggle, Network toggle instead of the leaky LineageOS approach, per-connection MAC randomization, fixes for many data leaks and much more.
GrapheneOS provides much broader app compatibility than CalyxOS via sandboxed Google Play. Apps forbidding using an alternate OS via the Play Integrity API is an issue for any alternate operating system and it's known that spoofing the device integrity check for Google certification is not a sustainable approach that will keep working. It already doesn't work consistently.
CalyxOS is not a hardened OS. It greatly reduces security vs. AOSP via added attack surface, rolled back security and slow patches.
Compatibility with Android apps on GrapheneOS is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer:
https://grapheneos.org/usage#sandboxed-google-play
Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the problematic microG approach.
https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.
https://privsec.dev/posts/android/choosing-your-android-base... is an article with more long form comparisons between OSes.
GrapheneOS provides much better privacy than CalyxOS including features like Contact Scopes, Storage Scopes, per-app Sensors toggle, Network toggle instead of the leaky LineageOS approach, per-connection MAC randomization, fixes for many data leaks and much more.
GrapheneOS provides much broader app compatibility than CalyxOS via sandboxed Google Play. Apps forbidding using an alternate OS via the Play Integrity API is an issue for any alternate operating system and it's known that spoofing the device integrity check for Google certification is not a sustainable approach that will keep working. It already doesn't work consistently.
CalyxOS is not a hardened OS. It greatly reduces security vs. AOSP via added attack surface, rolled back security and slow patches.
Compatibility with Android apps on GrapheneOS is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer:
https://grapheneos.org/usage#sandboxed-google-play
Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the problematic microG approach.
https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.
https://privsec.dev/posts/android/choosing-your-android-base... is an article with more long form comparisons between OSes.
GrapheneOS provides much better privacy than CalyxOS including features like Contact Scopes, Storage Scopes, per-app Sensors toggle, Network toggle instead of the leaky LineageOS approach, per-connection MAC randomization, fixes for many data leaks and much more.
GrapheneOS provides much broader app compatibility than CalyxOS via sandboxed Google Play. Apps forbidding using an alternate OS via the Play Integrity API is an issue for any alternate operating system and it's known that spoofing the device integrity check for Google certification is not a sustainable approach that will keep working. It already doesn't work consistently.
CalyxOS is not a hardened OS. It greatly reduces security vs. AOSP via added attack surface, rolled back security and slow patches.
Compatibility with Android apps on GrapheneOS is also much different. GrapheneOS provides our sandboxed Google Play compatibility layer:
https://grapheneos.org/usage#sandboxed-google-play
Can run the vast majority of Play Store apps on GrapheneOS, but not CalyxOS with the problematic microG approach.
https://eylenburg.github.io/android_comparison.htm is a third party comparison between different alternate mobile operating systems. It could include many more privacy/security features but it's a good starting point.
https://privsec.dev/posts/android/choosing-your-android-base... is an article with more long form comparisons between OSes.
Android has monthly, quarterly and yearly releases. Other Android OEMs only ship the monthly security backports with only all of the Critical/High severity fixes, not most of the Moderate/Low severity fixes including most privacy fixes. This is PARTLY addressed by using an alternate OS shipping these patches, but every alternate OS available for those devices rolls back security in a lot of ways. Firmware and a lot of the device support code comes from the OEM in practice. Running Android 14 QPR2 on top of Android 12 kernel / drivers is possible but will be missing the security improvements for a huge portion of the OS.
The batteries in Pixels aren't trivial to replace without damaging the device, but it's officially supported and there are official parts available:
https://www.ifixit.com/Device/Google_Pixel
We simply can't support insecure devices without the basics. Our hardware requirement list includes very basic things not provided by most Android OEMs along with more advanced features such as MTE which we now consider basic requirements for decent security. We want to support other devices, but those devices must meet these requirements. Memory tagging is a baseline feature supported by standard Cortex ARMv9 cores. It's unfortunate that Qualcomm is not implementing support for it and that OEMs using an SoC supporting it are not bothering to set it up. It's sad having a feature available in the CPU architecture that's not usable due to the SoC or OEM.
(They support devices for slightly longer than the devices are supported upstream)
Def can't trust Apple, can't trust Samsung. Google has managed to be the best. (Go ahead and @ me some cases that basically never hit the wild)
Yeah google does a better job.
Maybe you're special enough to be worth targeting for bespoke surveillance, I'm worried about avoiding ordinary mass-market adtech surveillance.
... oh this is some cryptocurrency thing, isn't it?
2. Is it very inconvenient to use as a daily driver? How often phone just crashes and requires a few days of debugging? Will my bank app work on it?
2. No, it is very convenient. It has a sandbox for Google Play Services, which IMO is the best of both worlds as it means you can install all the proprietary crapware apps that make modern life tolerable, but Google Play doesn't have unfettered access to everything on your phone. If you want even more isolation you can set up a separate user and run all the Google Play stuff in a separate user account, which I did briefly try but personally I can't be bothered switching user all the time.
The phone has never crashed. My bank apps work.
I have a Pixel 6a.
As for it not working, were you running a Flatpak/Snap version of the browser? Apparently those are problematic with Web USB. I personally haven't tried on Linux yet (just Mac O's) but now that I've switched to Fedora I might encounter the same issue you did.
I always try the Web installer, to see whether it works now, but then end up doing the command line method (which is also pretty easy, compared to historically how Android phone flashing used to work).
The two major things I need from my phone is good camera quality and being able to use Google Pay which is useful where I'm at.
I've never used Google Pay so I don't know.
In fact, it's as easy as installing it through Play Store.
Google Pay will not work as GrapheneOS makes no attempt to masquerade as a Google-Certified device [0]
You can install it via the sandboxed Play Store. Trying to install it via Aurora Store won't work properly unless you set the proper device model.
Google Pay doesn't allow NFC payments on an OS that's not certified by Google. It checks via Play Integrity. You can use a Pixel Watch with GrapheneOS to work around this since the Pixel Watch with the stock OS can make NFC payments itself without the OS on the phone needing to be Google certified. This is not a technical issue but rather a regulation issue. Play Integrity is absolutely not a real security feature but rather part of enforcing Google's licensing system which is presented as a way to defend against tampering with apps. In reality, it's very easy to bypass the device integrity mode via spoofing but not in a way that's suitable for a production quality OS which needs to keep working. It serves the purpose of stopping people using Google Pay and a subset of banking apps with a more secure OS but doesn't stop people using it with a much less secure OS where they're using one of the implementations of spoofing the checks. It's unfortunate. We support for Android's more meaningful hardware-based attestation but app developers need to whitelist GrapheneOS. It's covered at https://grapheneos.org/articles/attestation-compatibility-gu... for app developers, but we haven't yet made a big push to get some of them to do this. It's highly unlikely that Google Pay would do it without the EU saying they must.
There's a bug on many Linux distributions which was fixed in fwupd but is still present because they haven't updated it to a recent version. It interferes with reconnecting to the device when it reboots into fastbootd mode as part of the install. We cover it in our install guides now. fwupd usually loses the race to connect to the device to the CLI install tool but wins the race against Chromium's implementation, which is why it impacts web install more. This is likely what you experienced before we documented this fwupd bug and got them to fix it upstream. The problem is that even though fwupd fixed it a while ago, Debian and even the latest Ubuntu still have the bug.
As I understand, the way it works is that the project first has to scope out a hardware target that meets their security requirements before support can be considered and funded for. Just that right now there are no other phones that meet the requirements specified in https://grapheneos.org/faq#future-devices
If a phone met those requirements and was not made by Google, GrapheneOS would consider supporting it. In the case that Google didn't meet the requirements but a different phone did, GrapheneOS would support that phone and not the Pixels.
And that highlights the main goal of GrapheneOS - a security hardened mobile OS. (Note that better 'security' doesn't necessarily also mean better privacy protection).
The goal of GrapheneOS is providing a highly private, secure and usable mobile OS. It's not specifically focused on security above all else and we work on security in order to protect privacy. A huge portion of our work is on privacy features. We add many significant privacy features including Contact Scopes, Storage Scopes, per-connection MAC randomization, per-connection DHCP state, per-app Sensors toggle, per-app Network toggle doing more than blocking direct network traffic and much more. We have in-progress work on many privacy features including App Communication Scopes, improved state partitioning for Vanadium (privacy/security hardened Chromium) and a lot of other things.
We do a massive amount of work on usability including the whole sandboxed Google Play compatibility layer. We recently made an entirely new setup wizard and plan to replace all the legacy AOSP sample apps with better implementations. Our priority is the OS itself so replacing apps with multiple existing alternatives available simply isn't as high of a priority as improving the privacy, security and compatibility of the base OS. People can simply use another Contacts app so we don't heavily prioritize replacing the AOSP Contacts with our minor changes over focusing on important privacy and security features such as App Communication Scopes, 2-factor biometric unlock and a proper duress PIN/password without bypasses like existing implementations which are 3 current high priorities.
Yes, we want GrapheneOS devices meeting the same security standards we've set based on the baseline provided by Pixels while also including additional features we want to have. Pixels are not the best possible hardware but rather the best available hardware by far. There are no other devices even coming close to the current requirements. iPhones come close but are missing major things like MTE which we expect and of course don't have any alternate OS support and their security APIs are the ones needed by iOS which wouldn't work for what we need.
> meets their security requirements
Worth noting that there are privacy requirements listed there too including this one:
> Wi-Fi anonymity support including MAC address randomization, probe sequence number randomization and no other leaked identifiers
We could list a lot of other privacy, security and performance requirements which we take for granted. We're trying not to be overly strict with the requirements and are trying to keep it simple.
> If a phone met those requirements and was not made by Google, GrapheneOS would consider supporting it. In the case that Google didn't meet the requirements but a different phone did, GrapheneOS would support that phone and not the Pixels.
This is a factor in us advocating for MTE and other features even if they exist in a form we can use today. We do not take it for granted that future Pixels will continue providing what we expect. We push them to continue doing it and to keep important features we need. We know they're moving away from ARM Cortex cores to their own cores and we want them to provide an equally good MTE implementation. This means we need to advocate for MTE and get other people to advocate for MTE. If people eventually want to have CHERI and other more aggressive memory safety features, please advocate for what they've already shipped. Google enabling asynchronous MTE in production for their own code would be a huge security boost for Pixels and would also help assure that it has a future instead of being treated as a debugging feature they don't need to support on all their devices.
https://grapheneos.org/faq#future-devices
Pixels are the only Android devices meeting these requirements at the moment. Other devices do not currently come close to meeting these standards. This post is about MTE which is essentially a Pixel exclusive feature.
Simply receiving monthly and quarterly updates is essentially a Pixel exclusive feature and using an alternate OS providing them still leaves major parts of the firmware/OS without those improvements.
2 of the features on the requirements list are proposals we made to them which were accepted / implemented. There's another one of these pending for protection against data extraction via physical access through exploiting firmware boot modes on After First Unlock devices. Supposed to ship in April, and then we can add it to the list. The non-truncated key fingerprint display (we reported truncating it as a vulnerability) and the fantastic pinning-based hardware attestation support used by our Auditor app are the existing 2.
We've tried working with other OEMs but it hasn't panned out yet. We're often quite frustrated by Google but you'd probably be surprised at how much they have done based on our requests.
You can use a Pixel Watch or Galaxy Watch paired with GrapheneOS and make payments from the Pixel Watch.
As a daily driver, it's very mature and stable. The only downside for me is just a discovery of how much of the Google apps I use and how much they improve the stock experience. The biggest example for me was the keyboard (including speech to text). Thankfully (and something I give credit to Google for as they could make this hard or impossible), you can install most or all of those apps, including the Pixel Camera app, so you don't really have to give up much.
One important thing to note with Graphene is that they prioritize security, which is a little different than many ROMs in the past. For example, they highly discourage rooting due to its security implications, whereas in the past many ROMs came with root out of the box.
No but it is not the most convenient thing either. The Security Additions, Sandboxing Setup and a bit of slowness due to the hardened memory allocator are more annoying than just using plain android and clicking ok for whatever data it wants from you. Initial Setup and understanding what makes grapheneos different and how to use it's security features takes a bit though.
> How often phone just crashes and requires a few days of debugging?
Crashes? I haven't had one in my 4 years of usage. At least not a systemwide crash. Crashes that require days of debugging are in my experience not something that happens because hardware and software on pixel devices is well tuned for each other.
> Will my bank app work on it?
Depends on your banking app. Some work without any play services, most work with sandboxed playservices, very few do not work at all. Best you can do is tell us which bank you use and see if another user can confirm it works.
You can opt-out of secure app spawning if you deeply care about the small latency added to initial cold start app spawning time. You can opt-out of hardened_malloc with a per-app toggle if you find an app that's incompatible (memory corruption bugs caught by it) or which has bad performance with it.
There's no noticeable performance impact in regular usage. The only thing that was noticeable is the secure spawning (exec-based spawning) taking longer for initial app spawning time but that's entirely covered up by the animation time on current generation devices. There's a toggle for this for people who absolutely cannot cope with it, but we strongly recommend using secure spawning because many other security features depend on each app getting their own initial memory instead of being clones from the same template process (zygote) with a shared memory layout. It's not only about ASLR. It impacts PAC, MTE and any other partially or fully probabilistic mitigations.
> Crashes? I haven't had one in my 4 years of usage. At least not a systemwide crash. Crashes that require days of debugging are in my experience not something that happens because hardware and software on pixel devices is well tuned for each other.
GrapheneOS has user-facing crash reporting not present in the stock OS so users will definitely notice system process crashes they wouldn't have otherwise noticed. This helps us find issues like the Bluetooth crash the thread we posted was about fixing. We make all MTE detected crashes user facing since they tend to be serious issues and the crash reports tend to be useful for app developers or to us. We don't report all crashes by default but rather have a toggle for enabling that for the base OS in Settings > Security because it's too noisy. For example, sometimes hardware fails to fully wake up in the initial second of boot which automatically restarts the OS. It ends up reported as a kernel crash despite the fact that people wouldn't normally notice it. We got flooded with reports about this and had to reduce the scope of the user-facing reporting by default with opt-in to the rest.
Our features do find memory corruption bugs which were often not causing breakage in the stock OS but we believe this Bluetooth bug DOES often cause breakage in stock OS. It shows the other side of it which is that by finding the bugs, you can fix them, and you have fewer bugs remaining. GrapheneOS has dozens of fixes for upstream bugs. We try to report the security bugs upstream but their handling of non-security bug reports is awful so we don't bother for those.
> Depends on your banking app. Some work without any play services, most work with sandboxed playservices, very few do not work at all. Best you can do is tell us which bank you use and see if another user can confirm it works.
At this point, it's nearly just the apps that are deliberately trying to prevent using an alternate OS which don't work. Apps using Play Integrity API to forbid using an alternate OS is nearly anything that doesn't work. Some apps also have older implementations of manually detecting an alternate OS. For example, a tiny number of apps look at the call stack leading to starting their app and purposely crash it doesn't match the stock OS which happens with exec-based spawning enabled, which we could add a per-app toggle to work around but an alternative without more complexity would be making it show the same call stack. It's quite silly that this is a problem. Play Integrity API is replacing most of these custom hacks to detect tampering with apps, hooking apps, etc. Play Integrity API COULD allow using GrapheneOS by verifying it using hardware attestation but of course doesn't. Apps can use hardware attestation themselves to do this, but they don't currently do it. We're working on convincing at a few major apps to do that. It's covered at https://grapheneos.org/articles/attestation-compatibility-gu....
It's nearly indistinguishable from stock Android. It seriously Just Works. You may have to enable sandboxed Google Play Services to get some apps but other than that it's basically perfect.
As for how it works, it's been my daily driver OS on my Google pixel 6 nearly since the pixel 6 came out, and I've never once had it crash on me. Ever. It's never bugged out or needed me to debug or fix or maintain it in any way either. Every app I've ever tried just works on it too, as if I was using stock android, I literally don't even notice the difference honestly. Like sometimes I even forget this isn't what my phone came with. Personally my banking app, discover, works, but I don't know if others would, although I think they probably should since it has Google Play services and the bootloader is locked once you're done installing.
The only inconveniences if you may call them that have been in alerting me of things naughty apps were doing.
Actually, no. One problem I've had is that external audio input via USB has not worked for me. Anyone else figure that out?
However, recently my wife and I travelled to Orlando Florida to visit Disney World and Universal Studios. While their apps mostly worked with sandboxed Google Play Services, I did have some annoying issues. The My Disney Experience app gave me a lot of glitches related to Location (it was intermittent but I would occasionally be told I need to be in US or Canada to do something important and we had to use my wife's phone as a workaround) and I found myself unable to log in to my account on the Universal App (again, worked fine on my wife's stock Samsung Galaxy so pretty sure it was GrapheneOS).
Another limitation is that if you use Google Wallet to make credit card payments, this is unsupported since Google will not certify GrapheneOS. Wallet does work otherwise.
Uber works just fine for me. Other than that, I don't use any proprietary apps.
If you intend to stick mostly to FOSS apps you shouldn't have any issues. Most proprietary apps will work with sandboxed Google Play Services, but if any of those are mission critical for you then be warned that you might run into some annoying issues like I did with Universal Studio & My Disney Experience.
Yes that means google will get your location, but it's still better than going back to stock which is also better than any other third party skin in terms of privacy/security.
- There's no Google cloud backup, it uses Seedvault instead. It was a bit of a pain setting up some apps from scratch again (those that didn't have other backup mechanisms), but if I ever reinstall or switch to another phone running GrapheneOS I can copy over the backups and presumably restore them. It also supports some remote storage providers, but I haven't bothered with those yet.
- There's no Google Digital Wellbeing, which I used to track screen time and set limits for some apps. There are some limited alternatives on F-Droid, but I just ended up using Tasker to give me reminders when I'm staring at the screen for too long.
Other than that I didn't have any problems, and really enjoy the privacy features. Especially the ability to block network access per app, and set up custom storage scopes.
> and set up custom storage scopes
There's also Contact Scopes now. We've started work on adding App Communication Scopes for controlling that within profiles and we'd like to do similar features for Camera, Microphone and Location (the standard mock location feature is not great).
It's very easy to install with the web installer.
https://grapheneos.org/install/web
You can buy a device with it, but nearly anyone can use the web installer. It's particularly easy to use from Android, ChromeOS and macOS. Windows is a bit trickier since you need to install a driver. Desktop Linux requires installing udev rules, and some distributions with frozen software versions have a buggy service which interferes.
> Need special cables and to know a lot about jailbreaking Android devices, or will I be fine just following instructions?
Non-technical people can do it. You only need a browser with WebUSB. You don't need any special software.
> Is it very inconvenient to use as a daily driver?
Nearly the same as the stock Pixel OS with nearly as broad app compatibility if you use sandboxed Google Play.
> How often phone just crashes and requires a few days of debugging?
You likely won't experience significantly more crashes. It has user-facing crash reporting not existing in the stock OS so you'll notice crashes you wouldn't have known about it. Buggy apps with memory corruption may crash until you enable the per-app compatibility mode, ESPECIALLY if you opt-in to forcing MTE for all user installed apps.
> Will my bank app work on it?
If your bank allows a non-Google-certified OS, which most still do. Banks are gradually disallowing using a non-Google-certified OS and this essentially needs to be addressing as an anti-competition regulation issue. We're working on convincing banks to use https://grapheneos.org/articles/attestation-compatibility-gu... in the meantime.
The only issue is that GrapheneOS doesn't provide a built-in way to have root privileges and if you want root on your phone securely you will have to implement that yourself or use some third-party solution (e.g. building a userdebug build, using https://github.com/chriswoope/resign-android-image, using Magisk, etc.).
If not and you use something called the Aurora Store, prepare for nightmares. Or at least that has been my experience as far as inconveniences are concerned with the Aurora Store.
2. Not for me, but this highly depends on the use case. Graphene has good, honest documentation regarding this[0]. Banking is a pain point, because to the phone, GrapheneOS is an unverified third party system. Other than this, I have never seen a single crash, and I even use the YouTube apps with the Play store that it lets you install.
On top of that, clean and unified UX and usable features must be provided or the engineering is all for naught.
Compartmentalization is a far stronger security measure according to experience. See: Qubes OS.
Pixel 8 and Pixel 8 Pro are the main option with it. MediaTek and Exynos have theoretically added support for it but that doesn't mean any device with their latest flagship SoC theoretically supporting it actually has it available and working.
In hardened_malloc, we dynamically exclude the adjacent tags and previous tag used for an allocation slot. That provides deterministic protection against linear overflows and small overflows. For use-after-free, an access through a pointer to the freed allocation can't access it while freed or after being allocated again but rather needs to wait until the need time it's handed out again where there's a 1/15 chance it will have the right tag. This combines well with the other hardened_malloc security properties. It has FIFO/random quarantines for slab allocations and virtual memory, which delay reuse further and not deterministically. It avoids ever reusing memory locations between different allocation size classes until going above 128k, which are each in different regions with metadata all in another reserved region.
In the general case, MTE provides around a 1/15 chance for bypass due to currently only being 4 bits. It could be EASILY extended to support using 8 bits, and there are other free bits if you aren't using PAC. In theory, they could support up to 16-bit MTE for 48-bit address space or higher with a typical 39-bit address space. It's currently hard-wired to 4 bits which we've been told was chosen over 8 bits to enable storing the extra bits in ECC parity memory.
It's unfortunate that MTE is only 4 bits rather than at least being 8 bits. 1/15 is much worse than 1/255. It could be larger. MTE paves the way for tagging with a larger number of bits, including via a future iteration of MTE with 8 bits or more supported.
It's not specifically a bug finding feature. You can build very useful deterministic exploit protections out of reserved tags, even by simply using the standard 0 reserved tag. 1/15 chance of catching memory corruption in the general case is also nothing to sneeze at especially when combined with other features. If an exploit uses both an arbitrary read vulnerability and then an arbitrary write vulnerability that's 2 opportunities to catch it. It also gets combined with other features which make those exploits less reliable and harder to write. It doesn't exist in isolation. In hardened_malloc, it's just one part of what it does, but it's a huge advancement for it. Tagging the subset of stack allocations with possible overflows or use-after-scope will be another huge step forward.
It would of course be much nicer having massive tags ruling out inter-object memory corruption nearly completely. That doesn't mean MTE is not a good exploit protection and only good for finding bugs. MTE is a lot stronger than most existing exploit mitigations like SSP. SSP provides probabilistic protection against stack buffer overflows by moving the safe variables to the other side and checking a canary on return. If the attacker can leak the canary which is global to the process in userspace, they can write that out as part of it. It also only works against linear or very small (simply by adding padding) overflows. It only has deterministic protection against certain types of C string overflows via a 0 byte if the libc puts one at the start of the canary.
MTE an CHERI use a similar approach but MTE doesn't have large enough tags to provide strong security in the general case. MTE can provide strong deterministic security properties through reserved tags. Anything not tagged has a 0 tag and anything tagged has a non-0 tag by default since it's a default exclusion. You can exclude other tags statically or dynamically via instructions for this, but you can also simply use the 0 tag for internal usage such as freed memory while knowing that any tagged pointer can't access it.
In hardened_malloc, we dynamically exclude the adjacent tags and previous tag used for an allocation slot. That provides deterministic protection against linear overflows and small overflows. For use-after-free, an access through a pointer to the freed allocation can't access it while freed or after being allocated again but rather needs to wait until the need time it's handed out again where there's a 1/15 chance it will have the right tag. This combines well with the other hardened_malloc security properties. It has FIFO/random quarantines for slab allocations and virtual memory, which delay reuse further and not deterministically. It avoids ever reusing memory locations between different allocation size classes until going above 128k, which are each in different regions with metadata all in another reserved region.
In the general case, MTE provides around a 1/15 chance for bypass due to currently only being 4 bits. It could be EASILY extended to support using 8 bits, and there are other free bits if you aren't using PAC. In theory, they could support up to 16-bit MTE for 48-bit address space or higher with a typical 39-bit address space. It's currently hard-wired to 4 bits which we've been told was chosen over 8 bits to enable storing the extra bits in ECC parity memory.
It's best to not perpetuate the belief that it's dumb people because very few people think they're dumb and I've seen some absolutely amazing coders write some hilarious memory bugs. It just comes with the territory of those languages. It's not "if" it's "when".
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
-- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"
After 50 years of the Morris worm, only C Machines can fix the non existence of the mythical high skilled developer, and as Hoare predicted it is finally becoming a liability not to care about security.
Highly recommend that any Android developer with a single native library shipped with their app gets a Pixel 8 or Pixel 8 Pro to use MTE for finding and debugging memory corruption bugs. One of the major advantages of MTE is that you can use heap MTE with instrumentation only added to the allocators (such as malloc) without building all the code with it. Stack allocation MTE of course requires instrumenting those stack allocations.
I like how they snuck that in there :-D
As someone who spent years writing C and C++, but no experience with Rust, with this porting from C to Rust, how much refactoring is required? That might should be two different questions:
1. How closely does C translate directly over to Rust? Does Rust require some reorganization/refactoring?
2. How is Google approaching this? Are they trying to closely "translate" it as much as possible, or is this an opportunity for major rewrite/refactor?
Also very curious if anyone knows, will the Android Bluetooth stack ever be usable on a standard Linux distro desktop system?
My conclusion is that if you're writing a simple CLI or request-response thing, Rust is probably an easy port. More generally, if your code structure could work well with arena allocations, moving to lifetime-tagging of references isn't a big deal.
But if you're writing (admitted ugly) code with cyclic references the way a C programmer would :), Rust will feel like an uphill battle and is not the place to start. I need to start by restructuring the C++ code, moving ownership to a common parent. I think that'll make things better. Iteratively learning more about Rust, but continuing to work in C++ until the code has a better correspondance to Rust.
Edit: forgot the word simulator, and changed RefCell to Box.
Just so you know, RefCell does not inherently point to the heap. If you put a Box or something inside, sure, but on its own, it doesn't allocate.
Looking at what GravityBox was able to do, nothing in that can be done in a stock ROM without getting root.
Daniel Micay himself said that iphones are one of the best choices from a security perspective, GrapheneOS closing the gap. The reason is the close working together of hardware and software, which is very seldom done in case of Android devices - pixels being the sole exception that care about it, that’s why they are the only supported device.
Not much point in buying some fancy lock to your door, if there is a window open next to it.
Also, ios has a very locked down secure mode for the ultra paranoid.
GrapheneOS gets to focus on the weak points in Android and can make a bigger performance and memory usage sacrifice to achieve privacy and security. We can also add more user-facing features and toggles than either Apple or Google is willing to provide. This allows us to do many things they can't do. We care a lot about preserving app compatibility but we're willing to have opt-in features which break some apps, and we're willing to break apps with severe memory corruption bugs by default with an opt-out toggle to get them working. GrapheneOS aims to be nearly as easy to use as the stock Pixel OS once we do more work on the out-of-the-box experience and bundled apps, but we're willing to have more complex privacy and security options available for people who can deal with it. We see the starting point of AOSP as an already very good base relative to other modern operating systems.
> Daniel Micay himself said that iphones are one of the best choices from a security perspective, GrapheneOS closing the gap.
I haven't said this about current era GrapheneOS. You're referring to outdated comments from 4 years ago. Pixels, AOSP and GrapheneOS have all massively improved since then. Pixels with the stock OS have competitive security with iOS. GrapheneOS is not closing a gap with iOS on security. It is closing a gap on privacy and also surpassing it with features like Contact Scopes.
> The reason is the close working together of hardware and software, which is very seldom done in case of Android devices - pixels being the sole exception that care about it, that’s why they are the only supported device.
AOSP is developed largely with and for Pixels, but that is not why they're the only supported devices for GrapheneOS. They're the only supported devices because they're the only devices meeting the security requirements listed at https://grapheneos.org/faq#future-devices. If you ignore the differences in APIs between iOS and Android while pretending that the iPhone supported alternate operating systems, it does not meet that full requirements list either. The lack of MTE is a simple example.
It's presented as being for the ultra paranoid but what it does is mainly reducing huge amounts of attack surface created by default enabled Apple services. They're basic security measures rather than something super advanced and niche. It's all grouped together into one setting with some aspects impacting usability a lot without being able to get most of the features without that, which was their choice, and is what makes it into way more of a niche feature than it has to be.
These Apple services/features don't exist for GrapheneOS in the first place. People use Signal or the hardened Molly fork on GrapheneOS, not iMessage/Facetime, etc. Android already takes a more cautious approach to media handling in the stock OS. Lockdown mode mainly disables the permissive defaults of Apple services/features and provides attack surface reduction for Safari. GrapheneOS has Vanadium features that are similar such as JIT being disabled by default but beyond that those browser parts of it there isn't a lot that's applicable.
Of course I could not have known how the state of security, or your opinion of it has changed in the meanwhile.