[phh]

This article largely misses the point from the Linux kernel's point of view.

They have always said "Every bug is a security bug". I don't know about more global content, but at Kernel Recipes (2019?) gregkh took a Pixel that was running latest Google security patches that contained all CVEs. Then looked at non-CVE patches he merged in his LTS. And it took him less than an hour to find a DoS vulnerability.

I understand the author's frustration from the Linux Kernel community to not want to classify bugs, but the reality is that a huge portion of the bug fixes are actually security fixes [1], so between requiring 20% of the patches to be merged, and 100%, is there really a point?

The author mentions Cyber Resilience Act, and I believe that Linux Kernel team created this CNA /on purpose/ to have an impact on the CRA. They believe that the only way to have a secure Linux Kernel is to have an up-to-date Linux kernel. (cf https://social.kernel.org/notice/ARWvggnOvXny0CUCIa ). With the CRA enacted, doing such a every-bug-is-a-security-bug CNA is a way for them to enforce their view.

[1] FWIW, my personal opinion there is that this shows that Linux's monolith architecture is getting old, but I see nothing that could reasonably replace it. I think that "the dream" would be to have a LKL-like linux "arch" to compile every driver as an independent process of Hurd, with GKI-like stable-ish ABI.

[Avamander]

> They have always said "Every bug is a security bug".

If you can't reason about your codebase to a sufficient extent to actually determine that then something is very wrong.

If everything is a CVE, nothing is. That approach just wastes a lot of time and effort making people not so familiar with the codebase (as the maintainers) do triage.

I hope they get burnt quick by this approach.

[eqvinox]

> If you can't reason about your codebase to a sufficient extent to actually determine that then something is very wrong.

Linux kernel developers are entirely capable of assessing this. They're just refusing to do it for someone else's definition of a "security bug".

"Every bug is a security bug" means "we fix things when they need fixing, categorizing the fixes is not our job and you'll need to do that yourself".

As such, the current new approach is in fact a concession, there's now a broad pre-categorizing of fixes you can work off.

> making people not so familiar with the codebase (as the maintainers) do triage

You seem to be under the impression that you hadn't needed to do that before. Which, to be fair, worked for a long time. From an engineering perspective this was always a case of "skipping inspections and verification", because the Linux community never agreed to do that work on top of providing the system.

> I hope they get burnt quick by this approach.

How would they get burnt by this? Social pressure from other kernel developers (or even outside) isn't going to have that effect. The only possible influence would be from employers paying for Linux work — in which case it's a perfectly reasonable discussion about spending paid time on security issues.

[Avamander]

> Linux kernel developers are entirely capable of assessing this. They're just refusing to do it for someone else's definition of a "security bug".

Then instead of this, don't? It's utterly childish.

> How would they get burnt by this? Social pressure from other kernel developers (or even outside) isn't going to have that effect.

Fewer organisations willing to cooperate with them, for one? Social pressure comes in many forms and shapes, there's no way it won't have any effect.

> The only possible influence would be from employers paying for Linux work

They're going to be paying someone else to provide a clean feed instead of the organization that deliberately hinders these efforts.

[eqvinox]

> They're going to be paying someone else […]

And that's perfectly fine, it's open source software. Either way someone gets paid to look at the patches, which is my point.

If you want to do it in a cost-effective manner, you'll find other people with the same requirements, since the work result is "shareable".

> […] instead of the organization that deliberately hinders these efforts.

There is no such organization, and it feels like you have very little understanding of the organizational (and funding) structures behind the Linux kernel. I really can't extend my comments into a full-blown explanation of this, sorry.

(No, the Linux Foundation does not perform the role you're implying: they don't currently and likely never will sell a "clean feed".)

> Fewer organisations willing to cooperate with them[…]

I have no data on this but it is entirely reasonable (and I believe it likely) that the current behavior was requested (or encouraged) of involved organisations and people by cooperating organisations and people.

[Avamander]

I think you got a bit confused.

> There is no such organization

There is such an organization, the Linux Foundation is the CNA being the hindrance to these efforts. And yes, they won't perform the role, someone else will and they will be paid for it.

For some that's fine, I find it a significant amount of wasted effort, confusion and potential issues.

[eqvinox]

>> They're going to be paying someone else to provide a clean feed instead of the organization that deliberately hinders these efforts.

You were implying the Linux Foundation is attempting to get paid for providing said "clean feed".

Anyway, this has devolved far enough.

[Ed.: the Linux Foundation isn't even the CNA, shame on me for accepting that without verifying. The actual CNA is kernel.org. https://www.cve.org/Media/News/item/news/2024/02/13/kernel-o... ]

[viraptor]

> If you can't reason about your codebase to a sufficient extent to actually determine that then something is very wrong.

The environment where we write critical code the way we do now is very wrong. It's actually not that easy to figure out if something is exploitable or not. What if you add heap grooming? What if you enable another specific feature? What if an application fights for the same lock? What if measuring the time it takes to fail allows you to defeat aslr? People use exploit chains rather than independent ones these days and there are examples of clever cases of single-byte overflows turning into RCE.

Sure, there are going to be cases where you're really really sure something can't be used, because for example the bug only produces a null dereference and an oops. Then someone else comes along and proves you wrong https://googleprojectzero.blogspot.com/2023/01/exploiting-nu...

[Avamander]

> The environment where we write critical code the way we do now is very wrong. It's actually not that easy to figure out if something is exploitable or not.

Then the correct approach is not to cause "CVE fatigue" that can cause significant second-order effects. Not to mention the fact that who else is better suited to make that assessment? It's unavoidable that an assessment still has to be made because fundamentally there are use-cases where touching a working system has to have a really good reason. This will result in actually important things not getting patched because not-kernel-experts had to make that decision.

I also can't imagine large vendors being forced to follow a significantly more frequent update cadence also choosing to retain their current level of QA. Best case we're going to get more frequent less tested updates, worst case we're going to deploy an actual vulnerability due to some low-importance bugfix (with an assigned CVE).

[mnau]

CVE is just a identifier. CVSS should assign a score.

I would require all CVE to ha attached exploit demo code. Otherwise it's shouldn't be CVE