Linux kernel becoming their own CVE Numbering Authority (CNA) is wasting resources they'd have previously put towards higher quantity and quality backporting. We've noticed a drop in both for the stable/longterm branches and particularly Android Generic Kernel Image LTS branches.

We've had around 2.5 years to evaluate impact of Generic Kernel Images. Our conclusion is that this caused more harm than good to GrapheneOS.

Generic Kernel Images are supposed to make kernel updates easier via a stable ABI, but Pixels update all drivers for GKI updates anyway.

The stability of the ABI isn't perfect and many changes get reverted due to breaking the ABI. It also leads to even the GKI LTS branch with the latest merges of LTS releases to lag behind, particularly recently. We attribute some of that to the resources wasted on their CNA work.

CVE system did not work for the Linux kernel either way, but it's certainly not fixed through making nearly every backport into a CVE and ignoring anything not backported. We don't particularly care about it but rather our concern is wasting scarce resources on something useless.

Barely any resources are dedicated to stable Linux kernel releases. There's very little testing and review. There have been multiple filesystem corruption bugs backported to ext4 and f2fs recently. Some didn't exist in mainline but rather are from missing interdependent changes.

GKI LTS branch reverting a bunch of commits changing the ABI, working around the changed ABI in other cases and lagging behind is making it harder for us to deal with these issues. It'd be smoother upgrading the kernel and fixing API/ABI conflicts. ABI isn't fully stable anyway.

Android reached the point where mainline kernels were usable beyond needing out-of-tree drivers for hardware and the Tensor Pixel drivers are way less invasive and easier to port to new releases. GKI has made a mess of it, and it doesn't even make it easier for Pixels but harder.

5.10 kernel drivers for Pixel 6 were ported to 5.15, 6.1 and 6.6. They simply haven't decided to move to a newer branch yet. The kernel for Pixel 8 doesn't bother having a device kernel tree anyway but rather uses generic sources for GKI and all the drivers, so what's the point?

We're increasingly scared of updating LTS revisions and it does not help that the GKI LTS branch is lagging a bit behind since it's not lagging behind due to any further stabilization but rather lack of resources to keep up. Any LTS revision with f2fs changes is terrifying now.

Unlike the stock Pixel OS, we've avoided shipping common f2fs corruption bugs in production by being way ahead on LTS adoption while narrowing avoiding shipping new serious issues. Has been way too close for comfort and we have low confidence in any LTS release with f2fs changes.

Generic Kernel Images have directly interfered with both hardening and performance due to the impact of vendor hooks working around not being able to change core kernel code. We don't want dynamic kernel modules but we're essentially forced into using them to avoid init bugs.

They've made the usual mistake of burning resources on branches by having 2 variants of each LTS branch (Android 12/13 variants of 5.10, Android 13/14 variants of 5.15, Android 14/15 variants of 6.1, etc.) and then making many overlapping branches from those to stabilize them.

We're unconvinced that the Linux kernel is headed in the right direction. It's not truly getting more robust or secure. The accelerating complexity and churn is opposed to both, as are the culture and tools. We're hitting more issues including on our workstations and servers.

@GrapheneOS cc: @gregkh

@GrapheneOS Nope, that's not why LTS merges are being done slower in the Android kernel trees, there are a variety of other external reasons why that has slowed down. Nothing to do with my CNA work, sorry to spoil your narrative.

You know, a simple email asking "hey, why is this going slower" could have solved all of this speculation...

@gregkh It's clearly not possible for 1 person to do all of this properly no matter how productive you can be. The fact that Google hasn't assigned more resources to GKI LTS releases and kernel.org LTS releases is ridiculous. Our issue is with Google and other companies expecting a tiny group of people to do all this especially as kernel complexity grows and the pace of development accelerates. All the problems we see with kernel.org LTS, GKI LTS and the CNA are from extreme lack of resources.

@gregkh We aren't opposed to far more vulnerabilities having a CVE assigned, but non-vulnerabilities shouldn't. There were far too few CVE assignments before. The number of CVEs being assigned now might reflect reality but many are the wrong bugs.

The goal is clearly getting distributions to ship the stable/LTS releases instead of cherry-picking. That would be nice, but we think the goal would be better accomplished through having far more people working on testing, review, backporting, etc.

@gregkh We're in full agreement cherry-picking fixes with CVE assignments didn't work, but kernel.org LTS releases don't have nearly enough backported themselves and don't have nearly enough testing/review.

Perhaps shaming companies/distributions into using LTS with CVEs will work but it would work better if there were clear criteria and few incorrect assignments which requires more resources.

Google has more than enough resources to trivially fund all this even if no one else is on board.