@KernelRecipes Sometimes people need reminding that CVEs are just a stand-in for the real goal: fixing vulnerabilities. The point of "the deployment cannot have any CVEs" isn't an arbitrary check list. The goal is to get as close as possible to "the deployment cannot have any vulnerabilities".
The Linux Kernel CNA solves the "tons of false negatives" problem (but creates the "a few false positives" problem), but the result is a more accurate mapping from vulnerabilities to CVEs.
@KernelRecipes So the conclusion from this is that anyone saying "we can't keep up with all the CVEs" is admitting that they can't keep up with all the current (and past!) vulnerabilities present in the kernel.
Either they don't have a threat model, can't triage patches against their threat model, or can't keep up with stable releases due to whatever deployment testing gaps they have.
There are very few deployments I'm aware that can, honestly. This is hardly new, but now it is more visible.
@KernelRecipes But this is why I've been saying for more than a decade, and others have said for way longer, that the solution is eliminating classes of flaws.
Bailing water out of the boat is Sisyphean without also patching the holes in the hull. But since we're already in the water, we have to do both. And the more we can fix the cause of the flaws the less bailing we need to do; so more Rust, safer C.
I look forward to finding design issue vulns instead of the flood of memory safety issues.
@kees @KernelRecipes
I think many people agree, the difficulty is to get there: it isn't really realistic to freeze C code while replacing it with Rust, which means the bindings will keep breaking while Rust code is developed, causing a lot of pain to whoever maintains the bindings (making subsystem maintainers say "not me")
This, as far as I can see on the mailing list I follow, creates some tension, and I predict this will continue to do so in the coming years, because there is no simple way to convert such a large active codebase with so many users
As an interested outsider the state of Linux CI is bizarre. It appears largely left to consumers and developers.
When the cycle time for feedback on the commit is days or weeks the dev for the commit has moved on to new work. It is difficult to get that person to care about your problem.
I see the KernelCI project however it is not clear if build failures on it are cause for a backout in for the commit.
@kbrosnan @kees @KernelRecipes
I think you are right: Linux CI is left to consumer and developers. The thing is, there isn't really anyone else. There is no enterprise owning an hosting the kernel. I think only 2 developers are paid by the Linux Foundation, with no infrastructure to do CI on every subsystem tree.
On the media side, I see 2 CI running tests, one from Google, the other from Intel, with someone from Cisco in copy.
That being said, you should expect days before getting feedbacks on a commit you submit for review (by people not paid to do so) a reasonably weeks (or months, for a significat change, or 20 years for PREEMPT_RT) before getting merged in the subsystem.
The main issue with the kernel is to maintain it. So, I guess, for many maintainers, if you can't maintain your code, maybe it's best to leave it out of the kernel tree.
@kbrosnan @jacen @kees @KernelRecipes The CI, while provides amazing value when setup properly, is expensive to run. Even on smaller projects as Mesa3D, it needs to have a team of maintainers to develop it and keep it running. Not mentioning the teams who cares about the physical farms. Same as people agree on one mainline, I think it would be wise for all involved companies to join #KernelCI and work on pre-merge solutions instead doing their own post-merge.
@pavel @KernelRecipes At the LPC CVE BoF, in a room filled with people who care deeply about this topic, there appeared to be consensus that the CNA has traded many false negatives for a few false positives. (I.e. we are now closer to the imagined objective reality of a 1:1 mapping between fixes and CVEs.)
In the past, with distros and researchers mostly causing the CVE assignments, the implied threat model was that of a distro, and didn't represent other models. (But still missed fixes.)
@pavel @KernelRecipes I think of the CNA as doing a first pass at CVEs, and then each deployment can continue triage based on their threat model. This is how it's always been, it's just that severity triage has been moved closer to where it is needed: with those that have a threat model to apply. What has changed is that there isn't yet a place for common threat models to share triage. This used to be the CVEs themself, but that left out all the other threat models and missed tons of fixes.
@pavel @KernelRecipes Deployments always had an obligation to evaluate vulnerabilities and fix them, but now it has become unavoidable and threat model mismatches are glaringly obvious.
Yes, it is possible that for a given threat model, there are now a ton of CVEs that will need to have their severity labeled as "don't care". But this was always true -- but no one triaged fixes, they triaged against the prior CVEs, which were a small subset of the distro threat model. Lots of fixes got missed.