←back to thread

GrapheneOS is the only Android OS providing full security patches

(grapheneos.social)
751 points akyuu | 1 comments | 06 Dec 25 13:58 UTC | HN request time: 0s | source
Show context
raggi ◴[06 Dec 25 20:15 UTC] No.46176285[source]▶
Understaffed gift product wants 1 week cycles.

OEMs want 2-4 month cycles.

This is a perfect representation of the state of the software industry.

replies(1): >>46176387 #
luca020400 ◴[06 Dec 25 20:32 UTC] No.46176387[source]▶
I don't think that's a fair comparison.

OEMs have quite a lot of extra steps before releasing any build to the public.

They have to pass xTS, the set of test suites required before getting certified by Google, possibly carrier certification, regulatory requirements and more depending on where the build will be released.

There are "quicker" release channels for security fixes, but I don't think it's common for OEMs to only ship those without any other change to the system.

I don't think Graphene does anything of sort, they take what's already certified in the Pixel builds and uses it. Not like they could do much aside testing on the public part of xTS.

replies(4): >>46176838 #>>46177039 #>>46185168 #>>46185251 #
yaro330 ◴[06 Dec 25 21:43 UTC] No.46176838[source]▶
Yep. And GrapheneOS's changes to the kernels of devices they ship are laughably small, 20-30 commits at most. I don't think they even do any basic CVE checks on any of the source code.

Fuzzing, actual security analysis - all those things are done by Google.

replies(3): >>46177485 #>>46179349 #>>46185193 #
1. strcat ◴[07 Dec 25 21:12 UTC] No.46185193[source]▶
GrapheneOS has made substantial upstream contributions to the Linux kernel and Pixel drivers including vulnerability reports. Many of our kernel changes are for the out-of-tree drivers needed for Pixels which are in a separate repository from the Generic Kernel Image code from the upstream Linux kernel. We make important downstream changes including enabling many more of the upstream security features and adding important protections not yet available there. We worked with multiple upstream Linux kernel developers to get many of the changes we used to have upstream and therefore no longer need them. We have major kernel security improvements in development including more security-focused integration of hardware memory tagging, but indefinitely maintaining those downstream is not the way we try to do things.

We use much newer Generic Kernel Images than the stock Pixel OS as the base. Android 16 QPR2 was released this month and they finally shipped 6.1.145 from July 2025 for the Pixel 6 through Pixel 9 compared to us being on 6.1.158 which was the latest until yesterday (6.1.159) which will be incorporated soon. It's similar for our 6.6 and 6.12 branches compared to theirs. 6.6 is the current Pixel 10 and near future Pixel 6 through Pixel 9 branch. They only update the kernel revision every 3 months in quarterly/yearly releases so this is the smallest the delay gets right after a quarterly release. They'll still be on 6.1.145 until the next major release in March 2026 so the current delay of having the July 2025 kernel in December 2025 is not representative but rather is the small side of the delay. Shipping the newer LTS revisions is not easy due to frequent regressions both in the upstream code and to a much lesser extent in the out-of-tree drivers needed for Pixels which often need small changes to adapt them to the new LTS revisions.

GrapheneOS does a lot of deep security analysis and has proposed firmware, kernel and userspace exploit protections adopted by Google. We helped them get a bunch of vulnerabilities being exploited in the wild blocked off as whole classes of vulnerabilities including perf events, reset attacks on fastboot mode and much more. GrapheneOS is focused on addressing classes of vulnerabilities rather than individual bugs. Google puts a decent amount of resources into finding and fixing individual bugs and that isn't our focus. We get the bug fixes from the upstream project many months earlier and the Pixel driver fixes from them other than cases we fix them early due to finding them with hardware memory tagging which they don't use for the kernel even in Advanced Protection mode (or most of the base OS processes either, while we always use it for both with a much better implementation in userspace).

Most of our changes are in userspace where we don't try to collaborate with upstream developers as much as we do with the Linux kernel. Most of userspace is not developed as openly in a way we can properly collaborate.