The position of GrapheneOS is that attestation shouldn't be used to restrict people to an allowlist of hardware and operating systems. It can be used to without forbidding them from using what they want to use. However, if it's going to be used to make an allowlist of hardware and operating systems, then it needs to permit any any at least as secure as what they're permitting to be approved. Instead, they're enforcing Google's business model for licensing Google Mobile Services while not requiring secure devices at all. There's no security value in the current Play Integrity API which permits devices with no patches for 10 years.
Even the Play Integrity API strong integrity level only enforces being no more than 1 year behind on the official Android security bulletins which are 3-4 months outdated at release so that's nearly a year and a half behind of patches. It also has the massive loophole of permitting being arbitrarily behind on patches for earlier Android versions than Android 13, so even the strong integrity level permits a device launched with Android 8 with no patches applied since then. That's not a security check, it's a business model check to lock out alternatives not licensing Google Mobile Services. The licensing terms for Google Mobile Services have been found to be illegal in multiple countries. Google enforcing agreeing to those terms with the Play Integrity API is a truly extraordinarily violation of antitrust laws. Governments are not only failing to act but adopting it themselves. It's going to be looked back on as a massive failure for technology regulation/legislation along with government tech policy beyond that.
Dual booting would sacrifice a lot of the hardware-based security feature integration and would be much further from passing attestation checks. GrapheneOS fully supports hardware-based attestation but Google doesn't permit it in the Play Integrity API. Directly booting the fully unmodified stock OS is required to pass the hardware attestation checks for the stock OS. GrapheneOS appears as GrapheneOS in the attestation metadata and a dual boot setup would appear as that specific dual boot setup. Since it would have a bunch of security sacrificed for it, it would be far harder to convince services to permit that. It would be counterproductive.
GrapheneOS has near perfect app compatibility other than the Play Integrity API banning it from the overall tiny number of apps using it. It has per-app compatibility toggles for privacy and security features which trip other anti-tampering checks, find memory corruption bugs in apps, etc. There are a couple known compatibility issues from anti-tampering checks from the secure spawning feature but it has a toggle.
The stock OS isn't what's needed but rather directly booting it from the firmware with 0 modifications. Dual booting would require booting something else and major modifications to deal with hardware APIs not designed for multiple operating systems using them at the same time. Secure element / TEE APIs including the hardware keystore and attestation, etc. are not designed for dual boot. A/B updates, verified boot, firmware updates, etc. would need to be dealt with by the bootloader system. It would be complex and messy. The end result would not be a hardened device or one compatible with standard attestation checks.
Dual booting would be much further from passing attestation checks and would be incompatible with a bunch of the hardware-based security features. The boot slots are needed for A/B updates and include the firmware partitions. They're not useful for this and don't provide useful functionality for it. It would be entirely possible to build a bootloader for loading multiple different operating systems but it would be a hacked together mess without proper firmware updates or security. It would require heavily modifying both GrapheneOS and the stock OS to fit them into it. It would require losing a lot of the hardware-based security integration. What would be the point? The end result would be much further from passing attestation checks than GrapheneOS. GrapheneOS has near perfect app compatibility with the exception of the Play Integrity API. Other anti-tampering checks are largely compatible with GrapheneOS with the exception of tripping from certain hardening features which is increasingly being resolved with workarounds and there are toggles to avoid it already.
GrapheneOS has full support for 10th generation Pixels. It was much harder to add initial support for them than past generation Pixels but it isn't harder to maintain now that they're supported.
There should be multiple 2027 Motorola flagships meeting all the requirements for GrapheneOS. They'll be providing official support for it and they're already working on porting GrapheneOS to their devices.
> It can be done, fairphone rather famously did it once.
No, they ported a new major Android release beyond what the SoC officially supported. They had already stopped providing firmware, kernel or driver security patches long before that point. They did what LineageOS regularly does by porting a new major Android release to hardware not officially supporting it. Unlike LineageOS, they had to convince a company to certify it as meeting the CDD/CTS requirements. Most OEMs including Fairphone have major CDD/CTS violations but yet still get certified in practice so that doesn't really mean as much as you'd think. It's common for Android OEMs to break functionality tested by the CTS and yet somehow they have certification. This is part of why the Play Integrity API's flimsy justification for the highly anti-competitive approach it uses is such nonsense.
Even the Fairphone 5 already lacks standard Linux kernel security patches due to having an end-of-life kernel branch. Fairphone doesn't provide anything close to proper updates.
Qualcomm offers up to 8 years of major Android version updates and basic security patches for their firmware and drivers. They charge money for each year of support. It's there if OEMs are willing to pay for an up-to-date SoC and pay for many years of support.
QUIC still works fine on GrapheneOS. GrapheneOS only removed a way to ask the OS to close a QUIC connection automatically in case the app dies, etc. It's an optimization from a server perspective since it avoids the server thinking the connections are still open and keeping resources assigned to them until the idle timeout it has configured followed by having to go through a connection shutdown process. It's not an optimization from a client perspective.
GrapheneOS also has fixes for around 5 other VPN leaks and more fixes on the way. Android currently implements VPNs in a way that's prone to leaks due to VPNs being per-profile but profiles not using their own network namespaces yet and also depending on central services for the DNS resolver and various other things which have to properly handle VPN support. We have plans to improve the VPN architecture in the future to make it very resistant to leaks. There will also be support for running apps or groups of apps in VMs which can have even stronger protection against it.
Pixel 10a is essentially a proper Pixel 9a. It uses the Pixel 9 SoC and Pixel 9 cellular radio compared to the Pixel 9a using the cellular radio used by 8th gen Pixels. The 9th gen Pixel cellular radio was a huge upgrade for connectivity and power efficiency so it's a major advantage for the Pixel 10a over the Pixel 9a. They're budget devices and definitely have significant compromises for the display, wireless charging and other areas.
AOSP and GrapheneOS have a small allowlist of socket types in the SELinux policies preventing using AF_ALG outside of the dumpstate service used to gather system wide debugging information for bug report zips. It's not available as attack surface on AOSP-based operating systems in practice.
The vulnerability also isn't present in standard AOSP GKI kernels (including the stock Pixel OS) or GrapheneOS kernels since they use a minimal kernel with tons of functionality disabled. Other OEMs may enable it but SELinux policy won't permit accessing it. OEMs can weaken SELinux policy but they're restricted by the neverallow rules which disallow permitting apps to access a list of non-standard socket types including AF_ALG.
AOSP not permitting setuid/setgid binaries is certainly useful attack surface reduction but isn't how it blocks exploiting this vulnerability. It blocks it via SELinux policy having allowlists for socket types which don't permit AF_ALG to be used outside of the dumpstate service.
The vulnerability also isn't present in standard AOSP GKI kernels (including the stock Pixel OS) or GrapheneOS kernels since they use a minimal kernel with tons of functionality disabled.
Kernel attack surface is mainly done via SELinux policies on AOSP including ioctl command allowlists per device type such as permitted GPU driver ioctl commands, io_uring only being permitted for a few core processes and much more. AOSP uses seccomp-bpf for apps, etc. too but it's mainly SELinux doing kernel attack surface reduction in practice.
Lockdown Mode is focused on reducing the attack surface from Safari including the WebView and Apple services including iMessage/FaceTime. It does nearly nothing to protect against non-browser/non-messaging attack vectors in the OS or other apps. It's up to app developers to implement similar restricted modes and also baseline exploit protections. App developers need to explicitly opt-in to using the standard exploit protections used in many parts of the OS and Apple discourages doing it:
Even the Play Integrity API strong integrity level only enforces being no more than 1 year behind on the official Android security bulletins which are 3-4 months outdated at release so that's nearly a year and a half behind of patches. It also has the massive loophole of permitting being arbitrarily behind on patches for earlier Android versions than Android 13, so even the strong integrity level permits a device launched with Android 8 with no patches applied since then. That's not a security check, it's a business model check to lock out alternatives not licensing Google Mobile Services. The licensing terms for Google Mobile Services have been found to be illegal in multiple countries. Google enforcing agreeing to those terms with the Play Integrity API is a truly extraordinarily violation of antitrust laws. Governments are not only failing to act but adopting it themselves. It's going to be looked back on as a massive failure for technology regulation/legislation along with government tech policy beyond that.
reply