@vegard@kernellogger "a team of engineers" COULD do that (hint, Android does, by just taking the stable updates), but the paper shows that a specific "team of engineers" currently does NOT do that, which puts the users of those kernels potentially at a greater risk.
Read the paper, it's interesting.
Disclosure, I read it before it was published, but had no influence on it at all.
We start out at 2, and then after a year see what companies need/want/desire and are willing to work for having a longer period. Right now 2 years is rough, so we're doing longer.
Ideally I'd love to only do 2 years, maybe next year? Or it not, the year after that? I'm not going anywhere, we'll get there eventually as people learn that attempting to keep a fixed release on top of a highly moving project with thousands of fixes a month, is not a good idea for a variety of reasons...
You aren't alone, Linaro had a whole "webinar" about how the world is in trouble now that LTS releases are only 2 years, despite my objections directly to them that "this is not the case".
@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).
@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."
@clacke@joshbressers@kurtseifried@ljrk Yes, that is a good overview, and you can point at the managers and developers on the Google Android team for doing all of this hard work both in convincing people that this was a good idea, and actually doing the work to get stuff merged properly. I've watched them do this for the past 10+ years, it wasn't easy but has paid off a lot in my opinion, the security level of an Android device is worlds better than it used to be because of this effort.
@ljrk@kurtseifried@joshbressers It does not affect anything at all about in-kernel apis, there is no such stability rules or requirements, rather the opposite.
@ljrk@joshbressers@kurtseifried Based on the Android work I've seen happening, I doubt it. We have successfully run Pixel6 on every Linus -rc release for the past 3 years and that had 300+ out of tree drivers, not an issue. If you want to keep your code out of tree, you can, it just costs you money to do so, which companies have long understood for many decades now, it's their business decision. CVEs aren't going to change this at all, it does not affect the rate-of-change of upstream and stable releases at all.
@ljrk@joshbressers@kurtseifried The core Android portion of Google is very much NOT out-of-tree, they merge their code upstream almost always first before applying it to older Android kernel branches. See the yearly report at the Linux Plumbers conference for the past 5+ years where they what has been merged, what is left to be merged, and what is coming next, with pretty graphs and the like. They have a strong "Get your changes upstream first" rule with their OEMs and you can see the interactions with those companies uptream has increased dramatically over the past years been because of this.
ChromeOS portion of Google also has a strong "upstream first" rule, and is very good about taking updates and getting changes merged properly.
The Pixel out-of-tree stuff is due to other "reasons", but that is a separate division and there have been many patch submissions recently upstream to resolve that delta, so that is being whittled down.
@kernellogger Your data is going to be a bit skewed here, we have ONLY processed the v6.7..v6.7.1 and most of the v6.7.1..v6.7.2 commits so far for CVE-related stuff, which by far the majority have only Fixes: tags due to my travel schedule during those releases (i.e. I didn’t have the cycles to catch up with the cc: stable@ tagged commits. I bet the numbers will level out over time as we catch up with the rest of the commits in the v6.7.Y releases.
And it’s good to see people paying attention, thank you!
@kernellogger That's kind of a "if a tree falls in a forest and no one hears it, does it make a sound?" type of question, right?
Yes, if no one tells us that a specific issue/bugfix/whatever should have a CVE, and it doesn't get backported to stable (which will automatically trigger the review for CVE assignment), then you are correct, nothing will be assigned as obviously, no one noticed it.
This has taken a long time, I'd like to thank all the groups that helped, and especially the CVE group themselves. Our application was a bit different than other groups, but they understood that this is important for security overall.
It's been a good 6 years, and it was a solid kernel version for its time, but anyone still using it should have moved off it a long time ago as it has been showing its age for quite a while.
@warthog9 Many thanks to you and @monsieuricon 's work here and your continued work to keep vger alive all these years, it's one of the primary reasons that Linux development works so well.
@somenxavier@embeddedrecipes As we have said for decades, "there is no roadmap, Linux is evolution, not intelligent design". Submit changes you want to see happen if you want change, that's what everyone does!
@alwayscurious That is not what I am saying at all. You need to understand your usage model and know just exactly what portions of the kernel you are using and design your update schedule around that.
And be prepared to update/reboot at any point in time, after properly testing updates.
Companies using Linux in their "uptime-critical" products usually already know all of this and can handle it just fine. If not, then they are designed and supported wrong and that's a company problem, not a Linux problem.