> 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:
iPhones with Lockdown Mode enabled have definitely been exploited which is confirmed by leaked documents and statements from commercial exploit vendors. Lockdown Mode primarily reduces attack surface in Safari and from Apple services. It does very little to protect against other attack vectors such as messaging apps or physical data extraction.
You're thinking of Apple saying they haven't detected a case of a device with Lockdown Mode exploited in the wild themselves. Extremely few devices use Lockdown Mode and Apple has very little insight into successful exploits so there isn't much opportunity for them to detect it in the first place. Lockdown Mode bundles everything together and has very inconvenient changes many people won't accept. That greatly reduces usage even by people fully aware of it who want a lot of what it provides. For example, there's
Apple has said they haven't seen a case of a device with Lockdown Mode being exploited which is extremely misleading. Apple doesn't have that much visibility into devices being exploited and would mostly seen failed attempts. All of the Lockdown Mode functionality being bundled together contributes to it barely being used. There's no opt-out system for most of it beyond disabling it as a whole. Only a subset of the Safari restrictions can be partially disabled per-app and per-site which doesn't fully restore web compatibility. It's more that hardly anyone is using it and that Apple doesn't have much insight into apps and the OS being exploited successfully in the first place. Lockdown Mode is definitely useful but people should read about what it actually does and compare that to how devices get exploited. Apple's memory corruption exploit protections aren't tied to Lockdown Mode.
The initial supported devices will be flagships. They have regular, fold and flip variants of the flagships. The main advantage of flip phones is better one-handed use.
The initial supported devices will be flagships. They have regular, fold and flip variants of the flagships. The main advantage of flip phones is better one-handed use.
This is great to hear, I've been wanting a flip phone for a while. GrapheneOS on a Moto Razr would actually be incredible. Thank you for all of your hard work and being active in this thread. I'm looking forward to getting my hands on a Motorola with GrapheneOS :)
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.
reply