Post AmIYTzPYkEeEV3dFbs by kees@fosstodon.org
 (DIR) More posts by kees@fosstodon.org
 (DIR) Post #AmIS2w7MHaQ4k1prpQ by KernelRecipes@fosstodon.org
       2024-09-23T12:20:47Z
       
       0 likes, 0 repeats
       
       Keep it in mind! First one is a kind of personal mantra #kr2024
       
 (DIR) Post #AmIS2wllrKkIlMk8oq by KernelRecipes@fosstodon.org
       2024-09-23T12:21:25Z
       
       0 likes, 0 repeats
       
       From @kees
       
 (DIR) Post #AmIS2wm7q11smSuQN6 by kees@fosstodon.org
       2024-09-23T13:31:43Z
       
       0 likes, 0 repeats
       
       @KernelRecipes The continuity across upstream messaging has been clear since (probably before) 2017. Same observations then too: https://youtu.be/RKadXpQLmPU#t=2796"If you are not using a stable / long-term kernel, your machine is insecure" - @gregkh
       
 (DIR) Post #AmIS2xkODxEdnN6YIy by kees@fosstodon.org
       2024-09-23T13:39:28Z
       
       1 likes, 0 repeats
       
       @KernelRecipes Followed up by my more nihilistic take:https://youtu.be/b2_HAH2kX04#t=373Bottom line remains the same: we have to eliminate bug classes. I'm really excited by all the work that continues on this front between fixing the C language itself and the adoption of Rust. We continue to make steady progress, but can always use more help. :)
       
 (DIR) Post #AmIYTxaTWgBuqKiwLY by kees@fosstodon.org
       2024-09-23T13:50:07Z
       
       1 likes, 0 repeats
       
       @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.
       
 (DIR) Post #AmIYTybZk4fK02FKhU by kees@fosstodon.org
       2024-09-23T13:55:56Z
       
       0 likes, 0 repeats
       
       @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.
       
 (DIR) Post #AmIYTzPYkEeEV3dFbs by kees@fosstodon.org
       2024-09-23T14:06:19Z
       
       0 likes, 0 repeats
       
       @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.
       
 (DIR) Post #AmKgaZifqtJonM8yw4 by pavel@social.kernel.org
       2024-09-24T11:14:40.721824Z
       
       0 likes, 0 repeats
       
       @kees @KernelRecipes Greg & company is introducing so many false positives into the CVE system that CVEs are now completely useless for kernel. Good job! :-( (And calling it "a few false positives" is not really a good sign).
       
 (DIR) Post #AmKgaaFHtdPGQVP1lo by kees@fosstodon.org
       2024-09-24T15:22:03Z
       
       0 likes, 0 repeats
       
       @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.)
       
 (DIR) Post #AmKgab3yr9xKxj7Vmi by kees@fosstodon.org
       2024-09-24T15:28:18Z
       
       0 likes, 0 repeats
       
       @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.
       
 (DIR) Post #AmKgabfYbS0uqGhWM4 by kees@fosstodon.org
       2024-09-24T15:32:11Z
       
       1 likes, 0 repeats
       
       @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.