Discussion
@dalias I think you know I am one of the more critical of AI bullshit folks around.
You might note that the link is to lore.kernel.org, not to some AI peddler press release.
And if you click through, you will note these are all vulnerabilities with assigned CVE numbers, and these are all mentioned as resolved.
In other words, at least it seems like kernel developers themselves thought these warranted actual CVEs and spent time actually fixing them.
Also Linux developers:
"Vulns are just bugs. No special methods needed. OpenBSD are masturbating monkeys."
Also, please do note that grsecurity was open and free back in the day - before they tried to upstream their decent patches and attempts to making the whole system more secure.
At times they see the light on rare occasions.
@rysiek Is the 432 claim actually legitimate or is it slop vendor propaganda? What portion of them are a single issue split down into the smallest pieces possible to inflate the number of CVEs, hype up the "tools" behind them, waste responder time, and make defenders feel hopeless? What portion are even legitimate severity levels?
@dalias I think you know I am one of the more critical of AI bullshit folks around.
You might note that the link is to lore.kernel.org, not to some AI peddler press release.
And if you click through, you will note these are all vulnerabilities with assigned CVE numbers, and these are all mentioned as resolved.
In other words, at least it seems like kernel developers themselves thought these warranted actual CVEs and spent time actually fixing them.
@rysiek I really don't know what to make of that without taking a deep dive into the contents of the CVE assignments.
Internally among the kernel folks, there is a faction that very much wants to accept slop, and inflating the number of CVEs serves a narrative that they "need AI tools" to deal with the volume. I don't have any evidence that this is what's going on, but I'd be stupid to disregard the possibility.
The core problem right now is that we have a crisis of inability to trust large portions of the people we used to assume we could trust.
@dalias oh I am with you on that. But however you cut it – whether these are reasonable, serious CVEs that mark serious bugs; or, CVE diarrhea orchestrated to push for AI slop in kernel – this does not make Linux developers look like serious people.
I wonder ow many of those would have been prevented by using some kind of a modern compiled language that enforces at least some notion of memory safety. 
But it's difficult to have linked lists in such a hypothetical language so that's a no go.
Even though why would anyone use linked lists in this year of our kernel twenty twenty six?
https://arxiv.org/html/2306.06942v2
@rysiek fun fact... there were tons of bugs in the original Starcraft. When they did an analysis later they found out that everyone who needed linked lists (or variations thereof) basically went off and implemented their own version of it.
Yeah, I know the point is (probably) how unsafe pointers, and by extension, pointer-based linked lists, but I guess this supports that rather than going against it.
Look this is not about bashing Linux kernel developers specifically.
The point I am trying to make is: we all make mistakes, that's just the human condition.
But giving in to hubris, on the other hand, is a choice. And insisting that all is well and dandy and C is a "perfectly safe language as long as the developer knows what they're doing" is hubris.
@rysiek i'm never sure how to say this in a way that sounds convincing but linus, ingo, and essentially the entire power structure of the linux kernel have knowingly signed off on modifications introducing vulnerabilities which use a variety of tactics to evade notice including the abuse of git features such as backdating as well as inserting them within large swathes of other legitimate commits from the same contributor. module signature verification with ML-DSA was backdoored in march using a combination of these steganographic techniques and linus unambiguously and knowingly accepted it.
@hipsterelectron @rysiek Excuse me, but WHAT?
@rysiek i understand and respect your analysis here; i was among the vanguard of rust users i attended every mozilla rust meetup for years and i would love to see more linguistic innovation particularly since kernel development is in fact the one place where the C abstract machine model that enables portability does not apply, and where instead the semantics of code must be more directly negotiated with the hardware.
@rysiek Cats, however, are flawless entities incapable of making mistakes! 
@rysiek The issue isn't the language. The issue is the kernel's lack of any internal privilege boundaries. A memory safe language does not fix logic bugs in the implementation of memory/resource management. You fix this shit with an MMU not with language choice.
@dalias @rysiek Uh, what? The whole thing that makes memory unsafe languages so perilously dangerous for building secure systems is that UB can punch a hole right through whatever internal security boundary you might have designed. With a memory safe language you at least get the guarantee that the fallout of a bug can affect only the code/data that's explicitly connected to it at the level of the source code, allowing you to build up security boundaries.
@rysiek I'm allergic to rust. It's a sign of AI related corrosion
Install bonfire.cafe
Get the full app experience
