@kernellogger On the other hand, what's the difference between a distro branching off and backporting stuff from mainline and upstream stable branching off and backporting stuff from mainline? Why can the upstream stable maintainers do this and "a team of engineers" cannot? I think the difference could be better characterized and (if you pardon the expression) makes all the difference.
@kernellogger@corbet@gregkh In this talk, Jon repeats the line that future LTS stable kernels will only be maintained for 2 years -- is that current or just a remnant of the misconception from last year?
@monsieuricon@kees@kernellogger@corbet@gregkh Thanks for the clarifications -- I guess there is a subtle (but significant) difference between "they're going to drop that back to just two years of support for the long-term stable releases" (literal quote) vs. "we start out at 2 and extend as needed" (paraphrased FAQ + parent toot).
This is not news, of course, but it's interesting to see it spelled out. Are there other pages/lists like this? Maybe even a cap-to-root script/program..?
@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
@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.
@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.
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.
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.
@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.
@kurtseifried@kees@vathpela@gregkh I mean, yes... we're already doing all that, Oracle Linux kernels are based on stable and take all stable patches. But that's beside the point. I'm questioning the value of marking these particular patches as fixing vulnerabilities.
Anyway, the solution here (like I think @gregkh mentioned a couple of times) is that we need to (continue to) do our own screening and assessments in the context of our own products. Which is fair.
I'm fine admitting some wiggle room for borderline cases, but in this case the CVE description is literally "this can't actually fail" and "adding a check ... makes the static checkers happy".
@kees@vathpela@gregkh I don't want to get too pedantic here, but that corollary there looks like a prime example of the fallacy of affirming the consequent.
I really disagree, not all bugs are security bugs. They could be vulnerabilities at some point in the future (i.e. latent), but we have no evidence to say that they are today.
Don't get me wrong, I think these patches are good and should be applied everywhere, but they arguably do not fix vulnerabilities.
Note, however... this toot is not a commitment to completing anything 😛 I can already tell that I'm going to have trouble with some of the math here (and maybe performance).
I'm a Linux kernel contributor and open source enthusiast. My interests span from SAT solvers and cryptography to GPU shaders and compilers.For me, open source is about sharing knowledge and giving everybody access to technology. That's why I write about getting started with Linux kernel development, fuzzing, debugging, etc.I've worked on Ksplice and Linux kernel security professionally for 10+ years.The views expressed on this website are my own and do not reflect the views of Oracle.