[freedomben]

Just a point of clarity, GrapheneOS has the same support window that Google does, so they're not dropping support earlier than the vendor. The reason they drop support is because the burden of supporting an EOL device is way, way higher, especially for a security-oriented OS.

[strcat]

GrapheneOS provides extended support for end-of-life devices but we strongly discourage using our extended support releases. You can see we do that from https://grapheneos.org/releases and https://grapheneos.org/faq. We set an accurate Android security patch level field and do not downplay it with inaccurate claims about it. We do not do what other alternate operating systems by splitting out a Vendor security patch level field and claiming to provide all open source patches which is fundamentally not possible especially considering that a lot of the firmware is based on open source projects.

[SushiHippie]

Though the pixel 4 still gets updates from GrapheneOS, which didn't receive updates since October 2022 from Google.

So they support it even a bit longer than google officially does.

[strcat]

Yes, we provide extended support for end-of-life devices which had less than 5 years of proper support. We provide that for at least 1 year and no more than 2 years. However, unlike other alternate operating systems, we're completely honest about the insecurity and do not downplay it. We do not falsely claim to provide all open source patches and do not set an inaccurate Android security patch level. We try to strongly discourage using the extended support releases. We plan to add a notification about this to the OS which people can disable instead of only clearly marking it as insecure on the site.

[chasil]

Taking the "vendor security patch level" into account, it is impossible in some situations.

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.

[strcat]

We have extended support for end-of-life devices but discourage using it and make it clear that it's insecure. We dislike needing to provide it and many people don't realize we do because we make sure not to hype it up and instead try to get people to move to secure devices with full patches available. 6th gen Pixels moved to 5 year minimum support from launch and 8th gen moved to 7 years so we do not think extended support will make sense after the Pixel 5a. For now, we reluctantly provide it. There's a good chance we'll port the end-of-life Pixel 4a (5G) and Pixel 5 to Android 14 QPR2 to keep providing what we call "extended support" with all AOSP/GrapheneOS changes instead of "legacy extended support" with just backported patches. It's very unfortunate they didn't just extend the 4a (5G) and 5 to match the 5a lifetime despite it having the same SoC. It makes our life harder.

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.

[chasil]

That is interesting and useful discussion.

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.

[strcat]

They can have up-to-date AOSP but a significant portion of the OS consists of the driver, HALs, non-GKI kernel tree, etc. Android security patch level is meant to cover all of that. They're using it in a way that's not permitted for Android OEMs by redefining it to mean AOSP patch level for the parts of AOSP they build. Some things get built from AOSP for vendor executables and that are built into vendor executables. As an example with firmware, it will use the AVB library in the bootloader firmware. It also gets built into userspace driver libraries which are often proprietary, etc. Updating the portion of the OS they build via AOSP is not quite updating all the code from AOSP, and even if it was, the Android security patch level is not only for AOSP code. It covers firmware, drivers, etc. Check the recent Android Security Bulletins. The split Vendor security patch level shown in Settings is a LineageOS invention to show the REAL patch level for the overall device including firmware, drivers, HALs, kernel, etc. The whole point is meant to be that it's an overall patch level though. We just set the real patch level for extended support devices while providing the AOSP releases/backports. The only problem is the other alternate OSes making it look as if they're providing something more, but we aren't going to stop using it the official way. We're just not going to need extended support after the Pixel 5a since devices moved to 5 years and then 7 years of proper support.

[chasil]

Once again, thank you for this perspective.

I had no idea that a library was presented by the bootloader (AVB).

Interesting reading.

https://android.googlesource.com/platform/external/avb/

[strcat]

Pixels largely use open source code for the parts specific to Pixels (TEE, secure core, secure element, boot chain) but unfortunately they don't publish all the Pixel specific changes yet. They committed to publishing the firmware and hardware sources for the Titan M but provided no timeline and clearly didn't mean they would publish the sources for the current revisions but rather future ones. There's the OpenTitan project which they seem to use as a base since the Pixel 6 but that isn't what they committed to doing. We're still waiting for this and hoping they do it soon so that we can help audit this and report better bugs when we run into issues.