Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GrapheneOS is the only Android OS providing full security patches

grapheneos.social

Post reply on HN
Print view View original

351–360 of 467 posts

Re: GrapheneOS is the only Android OS providing full security patches

#351

Post by strcat »

raggi wrote: post #129
luca020400 wrote: post #94

Earlier quoted context omitted.

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…

> I don't think that's a fair comparison. Fair? > OEMs have quite a lot of extra steps before releasing any build to the public. AIUI updates are less stringent and burdensome than initial certification. Regardless much of the process is automated. Graphene has CI too. 3PL's taking 4 weeks to run automated tests is also absurd. There are some "manual steps" to run CTS-V but they shouldn't be weeks level burdensome ei…

Android CTS and VTS are open source so we can and do use those. They're filled with flaky and badly made tests along with enforcing anti-privacy and anti-security design decisions though, so not everything is supposed to pass. Google likes to enforce that OEMs aren't allowed to make certain kinds of privacy and security improvements which could impact app compatibility until Google decides to do it themselves in new major Android versions with new API levels forcing app developers to deal with it.

They don't allow adding our Network and Sensors toggles which are detected as modifications to the permission model. They don't detect Contact Scopes and Storage Scopes but they might be considered Compatibility Definition Document violations. We don't worry about this, our focus is passing the tests which are actually relevant including the ones we've added for duress PIN, hardened_malloc, our more advanced hardware memory tagging integration that's always on, etc.

If we wanted to get access to the proprietary GTS for Google Mobile Services to see how much sandboxed Google Play passes, we could, but we focus on real world app compatibility.

Re: GrapheneOS is the only Android OS providing full security patches

#352

Post by ysnp »

OsrsNeedsf2P wrote: post #97
nunobrito wrote: post #95

[flagged]

> Lest alone to use a distro with opaque financing sources that fully endorses government developed/sponsored platforms such as Signal and Tor. So you're against Signal, Tor, and Graphene, and suggest to instead use.. Lineage? Don't get me wrong, I love Lineage, it was my first custom ROM, but this seems a little tinfoil

It's inaccurate that GrapheneOS fully endorses Signal and Tor. The GrapheneOS founder was blocked by Moxie (when they were still leading the project) for criticising their approach. They have also warned countless times about the limitations and weaknesses of Tor.

Re: GrapheneOS is the only Android OS providing full security patches

#353

Post by ysnp »

blurker wrote: post #207
drnick1 wrote: post #119

Earlier quoted context omitted.

If you have a Pixel -> Graphene, if not -> Lineage. I personally don't care about "security" all that much, my main reason for using Graphene is freedom to use my hardware in any way I wish. This means unrestricted ability to run any program on the phone from any source. Sideloading restrictions don't apply to Graphene, and it is also impossible for state actors to impose things such as client-side scanning of text m…

That sounds amazing. I aspire to get a setup like yours. I am on a Pixel with the stock OS and I can't stand the way Google is pushing AI into everything on my phone. I haven't switched it to Graphene OS yet because I read that there are issues with NFC and a few other things. I assume this new phone won't have those problems so I think that will be my catalyst to do a big overhaul.

This depends what you mean by 'issues with NFC'. My understanding is that Google require an OS that is blessed by them for contactless payments in Google Wallet to work. That restriction applies to all alternative operating systems that aren't Google certified stock Android.

The OEM partnership would not change that.

In non-NA regions there may be more options for mobile contactless payments using apps that are not Google Wallet/Pay. So it also depends where in the world you are.

Re: GrapheneOS is the only Android OS providing full security patches

#354

Post by immibis »

amelius wrote: post #341
immibis wrote: post #317

Earlier quoted context omitted.

No. There are a few that claim to, but none of them are actually any good. Waydroid, for instance, requires that your kernel is compiled in basically "Android mode" (e.g. binder enabled).

How do the Android developer tools run Android apps on Linux then?

Inside a virtual machine which is easy to detect.

Re: GrapheneOS is the only Android OS providing full security patches

#355

Post by ysnp »

luca020400 wrote: post #94
raggi wrote: post #88

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.

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…

Hopefully you don't mind me asking this question, but didn't you work with people who managed to do exactly what you are suggesting with a fairly small team at Essential for a few years?

Re: GrapheneOS is the only Android OS providing full security patches

#356

Post by immibis »

fsflover wrote: post #272
immibis wrote: post #264

Earlier quoted context omitted.

Obviously you'd only choose hardware that works the way you want it to.

Hardware relying on free drivers is almost non-existent in the mobile world. There is nothing to choose from, obviously.

Then aim for freely distributable drivers. You can share copies of Raspbian, so it seems possible.

Re: GrapheneOS is the only Android OS providing full security patches

#357

Post by immibis »

mschuster91 wrote: post #181
immibis wrote: post #60

Earlier quoted context omitted.

Any one of us here could learn the skills to design a smartphone. It won't necessarily be good, but I remember that years ago, someone made one with a touchscreen hat and GSM hat atop a Raspberry Pi, rubber-banded to a power bank. I'm sure any one of us HN users could do this. And it worked. Quality only goes up from there. The problem is it won't run any apps, so you'll need to carry this open-source secure phone in…

> Any one of us here could learn the skills to design a smartphone. Unless you're Fabrice Bellard who literally created a 4G softmodem - no. It takes a whole lot of people (or, again, one genius Fabrice Bellard clone) to design a smartphone. You'll need AT THE VERY LEAST: 1) a SoC that has reasonably open device drivers and specifications - without that, all attempts are moot 2) a hardware engineer to deal with the P…

or you could slap a GSM shield on a Raspberry Pi.

Re: GrapheneOS is the only Android OS providing full security patches

#358

Post by strcat »

yaro330 wrote: post #114
luca020400 wrote: post #94

Earlier quoted context omitted.

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…

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.

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.

Re: GrapheneOS is the only Android OS providing full security patches

#359

Post by fsflover »

immibis wrote: post #356
fsflover wrote: post #272

Earlier quoted context omitted.

Hardware relying on free drivers is almost non-existent in the mobile world. There is nothing to choose from, obviously.

Then aim for freely distributable drivers. You can share copies of Raspbian, so it seems possible.

Then your hardware will turn into e-waste as soon as the vendor decides so and stops updating the drivers.

Re: GrapheneOS is the only Android OS providing full security patches

#360

Post by strcat »

luca020400 wrote: post #94
raggi wrote: post #88

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.

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…

We'll have the same update pace for security updates and major releases with the devices we're working on with our OEM partner. That's not specific to Pixels. It will in fact be easier to support the devices with the OEM partner due to them planning on doing most of the device support work including getting MTE working properly. For Pixels, we have to do a lot of work on device support, while for non-Pixels that work is going to be done for us. Our OEM partner is actively getting what's needed from Qualcomm including getting them to fix things. We're in direct contact with Qualcomm ourselves and plan to deploy new security features they've developed which are not yet available elsewhere.

Samsung and Google ship a small subset of the security preview patches early while we're shipping all of them. We're doing a lot of work to integrate and test those. We also have to port them from Android 16 to Android 16 QPR1 and now Android 16 QPR2. It seems they might start providing them for Android 16 QPR2 themselves but for now we had to port them for our QPR2 releases.

We also have to test and fix all the issues caused by us having much more advanced exploit protections including full system hardware memory tagging with a more advanced implementation. We uncover MANY upstream memory corruption bugs we need to fix. Features like Contact Scopes, Storage Scopes, 2-factor fingerprint authentication, etc. are not always easy to port to new versions. We still don't have early access to upcoming quarterly and yearly releases but we'll get it and then we can have day 1 updates for those instead of it taking days for an experimental release and around 1-2 weeks before it reaches the Stable channel. We intend to do much better than we are now, we just need the same early access OEMs have but don't actually use to make day 1 releases for major OS updates.

Post reply on HN