Conversation

Notices

1. Embed this notice
   Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org)'s status on Friday, 08-Mar-2024 21:35:02 JST Thorsten Leemhuis (acct. 1/4)

   "[…] It is clear that the current process is based on the learnings, and frustrations, the [#Linux #kernel's CVE] team has faced in the past. […] By taking this position, this effort is now duplicated across thousands of engineering teams ad infinitum, […]"

   Well, yeah, but guess what: maybe then the companies behind those engineering teams will join up and invest money to handle the problem "[…] at the source, in a central, efficient and reliable manner. […]". 😬

   https://amanitasecurity.com/posts/dear-linux-kernel-cna-what-have-you-done/

   • Embed this notice
     Vegard Nossum 🥑 (vegard@mastodon.social)'s status on Friday, 08-Mar-2024 21:34:56 JST Vegard Nossum 🥑

     in reply to

     • Lars Marowsky-Brée 😷
     • Greg K-H
     • Lorenzo Stoakes
     • Pavel Machek

     @ljs @kernellogger @larsmb @gregkh @pavel If we really need to know the security impact of each and every patch (which most distros probably do), then somebody has to do that analysis. Yes, it's going to be expensive in terms of manpower and effort. But it still needs to be done. That's why I'm hoping this will lead to more distros collaborating on this and the community effectively only doing it once, in one place.

   • Embed this notice
     Greg K-H (gregkh@social.kernel.org)'s status on Friday, 08-Mar-2024 21:34:56 JST Greg K-H

     in reply to

     • Vegard Nossum 🥑
     • Lars Marowsky-Brée 😷
     • Lorenzo Stoakes
     • Pavel Machek
     @vegard @ljs @kernellogger @larsmb @pavel "security impact" means you have to take into account your specific use case, and we have no idea what your use case is Remember, Linux is in cow milking machines, servers, helicopters on Mars, phones, utility meters, watches, mega-super-yacht-stabilizers, wind turbines, printers, cars, planes, trains, and more. Doing an accurate "security impact" is going to be different for all of those cases.
     
     To quote Ben Hawks, "It's hard to capture the fact that a bug can be super serious in one type of deployment, somewhat important in another, or no big deal at all -- and that the bug can be all of this at the same time. Vulnerability remediation is hard."
     
     His full post is worth reading: https://blog.isosceles.com/what-is-a-good-linux-kernel-bug/
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Lorenzo Stoakes (ljs@social.kernel.org)'s status on Friday, 08-Mar-2024 21:34:57 JST Lorenzo Stoakes

     in reply to

     • Vegard Nossum 🥑
     • Lars Marowsky-Brée 😷
     • Greg K-H
     • Pavel Machek
     @vegard @kernellogger @larsmb @gregkh @pavel I am pretty sure there are scripts involved here, look at Pavel's example.
     
     EDIT: Also on the 'go nuclear' point, the original email literally states 'the CVE assignment team is overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team."
     
     That very much speaks to going nuclear, every single 'bug fix' (however you want to define that, autosel for instance blurs lines) is likely to be quite a few. And given the use of scripts in stable process highly likely to be at least partially automated.
   • Embed this notice
     Vegard Nossum 🥑 (vegard@mastodon.social)'s status on Friday, 08-Mar-2024 21:34:57 JST Vegard Nossum 🥑

     in reply to

     • Lars Marowsky-Brée 😷
     • Greg K-H
     • Lorenzo Stoakes
     • Pavel Machek

     @ljs @kernellogger @larsmb @gregkh @pavel I posted that one myself a few days ago 🙂 And I disagree with that one having a CVE on account of the whole "small allocations can't fail" thing being so widely accepted to be true in basically all configurations. Greg's response was here, BTW: https://lore.kernel.org/all/2024022654-designer-rack-c644@gregkh/

     Looking over the list of recent CVEs, most of these are probably local DOS in various obscure drivers. But they do arguably fall within the definition of a vulnerability according to CVE.

   • Embed this notice
     Lorenzo Stoakes (ljs@social.kernel.org)'s status on Friday, 08-Mar-2024 21:34:58 JST Lorenzo Stoakes

     in reply to

     • Vegard Nossum 🥑
     • Lars Marowsky-Brée 😷
     • Greg K-H
     • Pavel Machek
     @vegard @kernellogger @larsmb @gregkh @pavel yes, I've generally not commented on this as a. I'm not involved with an enterprise kernel at this point and b. the complexities of the issue, but from my perspective it's the lack of acking how the _reality_ of how kernels are used by the companies which fund a huge amount of core dev.
     
     I mean even if you think the way it's done is awful there should be some acknowledgement of that fact, especially when people are explicitly saying 'dude we are in a position where we _have_ to filter through this stuff'.
     
     And I think the whole 'well there's a ton of bugs who knows which could be a security flaw' is dubious at best.
     
     Some bugs are very clearly more problematic or have more clearly been shown to be security flaws than others.
     
     Of course all this speaks to how incredibly crap the whole CVE system is as a whole, but I'm just not sure going nuclear is the way forward.
     
     I think the kernel taking control of the CNA side is _good_, the spamming aspect, seems not so good.
   • Embed this notice
     Vegard Nossum 🥑 (vegard@mastodon.social)'s status on Friday, 08-Mar-2024 21:34:58 JST Vegard Nossum 🥑

     in reply to

     • Lars Marowsky-Brée 😷
     • Greg K-H
     • Lorenzo Stoakes
     • Pavel Machek

     @ljs @kernellogger @larsmb @gregkh @pavel Agreed that the dialogue hasn't been great. However...

     I don't think they are actually "going nuclear" here. There are 3 volunteers going through all of the stable commits for things that look potentially security-relevant, and they have a vote. It's not like they are literally flagging every single commit. The CVE volume has gone up, clearly, but I think it's justified.

   • Embed this notice
     Lorenzo Stoakes (ljs@social.kernel.org)'s status on Friday, 08-Mar-2024 21:34:59 JST Lorenzo Stoakes

     in reply to

     • Vegard Nossum 🥑
     • Lars Marowsky-Brée 😷
     • Greg K-H
     • Pavel Machek
     @pavel @vegard @gregkh @kernellogger @larsmb the issue for me as an outsider to this (currently not employed within the kernel, though contributing to it a fair bit) is the utter denial that there are consequences like that coming from the pro- side despite the opposing side saying 'yes maybe we shouldn't care but customers care, regulators care, etc. etc' and the other side >/dev/null.
     
     Having a conversation starts with acking or refuting what the other side has to say, not acting like it wasn't said.
     
     Again, happy to stand corrected if I'm wrong here! Just my perspective.
   • Embed this notice
     Vegard Nossum 🥑 (vegard@mastodon.social)'s status on Friday, 08-Mar-2024 21:34:59 JST Vegard Nossum 🥑

     in reply to

     • Lars Marowsky-Brée 😷
     • Greg K-H
     • Lorenzo Stoakes
     • Pavel Machek

     @ljs @kernellogger @larsmb @gregkh @pavel It's really complicated... I'm myself on the distro side here (though speaking only for myself) and I see very clearly the additional work that this is causing. On the other hand... I do think this is actually moving things in the right direction, security-wise. The uncomfortable truth is that the kernel has a TON of bugs, many with security impact. This move really just puts it completely out in the open and forces everybody to acknowledge that fact.

   • Embed this notice
     Vegard Nossum 🥑 (vegard@mastodon.social)'s status on Friday, 08-Mar-2024 21:35:00 JST Vegard Nossum 🥑

     in reply to

     • Lars Marowsky-Brée 😷
     • Greg K-H
     • Pavel Machek

     @pavel @kernellogger @larsmb @gregkh I think it's important to realize that nothing has really changed in how patches are merged into either mainline or stable. The only difference here is that more commits are now designated as (fixing) CVEs. On the whole, that's probably a good thing; false positives are probably better for security than false negatives. This creates more work for distros, but arguably that's work they should be doing anyway. If we can collaborate more, that's even better.

   • Embed this notice
     Pavel Machek (pavel@social.kernel.org)'s status on Friday, 08-Mar-2024 21:35:00 JST Pavel Machek

     in reply to

     • Vegard Nossum 🥑
     • Lars Marowsky-Brée 😷
     • Greg K-H
     @vegard @kernellogger @larsmb @gregkh Dealing with spammer should not be part of distro's work. And no, "false positives are better" is not true in this case.
   • Embed this notice
     Lars Marowsky-Brée 😷 (larsmb@mastodon.online)'s status on Friday, 08-Mar-2024 21:35:01 JST Lars Marowsky-Brée 😷

     in reply to

     @kernellogger I think it's clear at this point that this isn't an unintended side effect.
     It is intentionally aimed to bring the system down through overload, probably in the hope that something better will emerge later.
     At best, it is "constructive destruction" - at worst, it is malicious towards the users and may spectacularly backfire on the trust towards Linux.

   • Embed this notice
     Pavel Machek (pavel@social.kernel.org)'s status on Friday, 08-Mar-2024 21:35:01 JST Pavel Machek

     in reply to

     • Lars Marowsky-Brée 😷
     • Greg K-H
     @larsmb @kernellogger I don't belive @gregkh is acting in good faith here :-(. https://lwn.net/Articles/961978/ makes it quite clear. How can we stop him?
   • Embed this notice
     Lars Marowsky-Brée 😷 (larsmb@mastodon.online)'s status on Friday, 08-Mar-2024 21:36:12 JST Lars Marowsky-Brée 😷

     in reply to

     • Vegard Nossum 🥑
     • Greg K-H
     • Pavel Machek

     @vegard @pavel @kernellogger @gregkh It's still an intentional attack on the CVE system. That's perhaps a fair aim, but it can't be denied it also causes strive, confusion, and pain for some.

   • Embed this notice
     Greg K-H (gregkh@social.kernel.org)'s status on Friday, 08-Mar-2024 21:36:12 JST Greg K-H

     in reply to

     • Vegard Nossum 🥑
     • Lars Marowsky-Brée 😷
     • Pavel Machek
     @larsmb @vegard @pavel @kernellogger I find it hard to understand how this is an "attack", when it was specifically authorized and endorsed by the CVE employees and board of directors? They knew exactly how many CVEs we would be filing on a weekly basis and how we would be evaluating them for inclusion. We went through many meetings and discussions before our application was accepted and our id submissions were allowed.
     
     They also asked us to backfill the database with our previously submitted GSD information, as well as everything that gets merged forward. That backfill work is ongoing and is the large volume of what is currently being assigned right now. That information has already been out there for years in GSD, putting it in CVE doesn't change the actual kernel commits or "security" at all, it's just that you might not have noticed the GSD entries (hint, the "bad guys" sure did...)
     
     The number of "new" CVE entries is a small % overall as we really have only processed the changes from v6.7.0..v6.7.3 or so. We are behind in the new stuff and will catch up soon there, help is always appreciated, if you see a commit you want assigned a CVE, just ask!
     
     As others have said, this hasn't changed how the kernel commits are merged at all, it's just calling stuff out that everyone should have already been looking at and merging already, with way more meta-data and information than has ever been done before for kernel CVEs, thereby actually raising the information level in the CVE database here (which is probably why the CVE board wanted this.)
     
     If companies are somehow dictating that they MUST look at and evaluate all CVEs, then they should be happy as many groups were intentionally abusing the CVE process for the kernel previously, making their life much more difficult (including the community's life, which is why we became a CNA.) That abuse has now stopped, to be replaced with a different workflow with way more meta-data produced to help make decisions easier. So far one of the biggest complainers was the company that was doing that abuse as they are no longer allowed to do that (to be specific, that was NOT SuSE).
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Lorenzo Stoakes (ljs@social.kernel.org)'s status on Friday, 08-Mar-2024 21:39:54 JST Lorenzo Stoakes

     in reply to
     @kernellogger you know being part of the kernel community involves actually PUSHING BACK sometimes instead of just repeating the 'company line'.
     
     So far it seems you are simply repeating Greg's points and ignoring the (copious) push back on this.
     
     Quite credibly this is one giant troll designed to essentially attack the whole broken mess of CVEs, many people have pointed out how this is an issue.
     
     It strikes me as quite naive to think that companies should now funnel cash + resources into filtering a ton of 'security' issues that are very obviously not, on top of the already questionable stable practices.
   • Embed this notice
     Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org)'s status on Friday, 08-Mar-2024 21:39:54 JST Thorsten Leemhuis (acct. 1/4)

     in reply to

     • Lorenzo Stoakes

     @ljs

     don't worry, I will speak up when I see the need; but reg. the CVE stuff and a lot of the critique wrt to how the stable team operates I seem to be somewhat in line with Greg's approach *or* think the problems need to be fixed elsewhere to improve things (the latter is on my todo list).

     And 'company line'? Come on, this is the kernel community, there is no company line, just individuals with a lot of different options 😇

     /me runs 😬

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Thorsten Leemhuis (acct. 1/4) (kernellogger@fosstodon.org)'s status on Friday, 08-Mar-2024 21:40:41 JST Thorsten Leemhuis (acct. 1/4)

     in reply to

     • Lorenzo Stoakes

     @ljs

     And wrt to "It strikes me as quite naive [...]": maybe, but it's a bit like better docs, regression tracking and some other unattractive work in kernel land: a lot of people want those things to be better, but its hard to find the money to pay people to do all that work.

   • Embed this notice
     Vegard Nossum 🥑 (vegard@mastodon.social)'s status on Friday, 08-Mar-2024 21:40:41 JST Vegard Nossum 🥑

     in reply to

     • Lorenzo Stoakes

     @kernellogger @ljs Two points here: 1) Yes, the bad guys are already doing this (sifting through changelogs and finding exploitable bugs), we should be doing it too, and 2) various companies and distros probably are probably already doing some parts of the work but it's done behind closed doors and we have no good mechanism for exchanging notes or collaborating at the scale necessary, so it ends up as duplicated for no good reason. I really do see an opportunity here for everybody to win

     Haelwenn /элвэн/ :triskell: likes this.