Linux kernel developers:
We know what we're doing, we have loads of experience!
Also Linux kernel developers:
432 Linux Kernel CVEs in 24 hours:
https://lore.kernel.org/linux-cve-announce/
*sigh*
37
Replies
·
0
Boosts
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 i would LOVE to see languages seek to map out this space by negotiating arrangements with hardware designers that enable compilers to generate code that achieves more powerful semantic guarantees than are available in plain C. that is the definition of engineering innovation.
@rysiek however, there's another path available here that i think you're eliding, which is that memory safety as a semantic regime is not a quality that requires a complete re-engineering of the compiler nor is it incompatible with C source code. C compilers in fact contain an immense degree of knowledge about the relative relationships between memory addresses. it is false and misleading (not you, but i have heard this so often) to claim that "undefined behavior" is strictly adversarial. the C standard, and the C abstract machine, declares it to be out of scope. this is very much where compilers have long had nonstandard extensions—that is also exactly how engineering innovation works.
@rysiek the question then becomes: how much work is it to retrofit memory safety into the mid end of a C compiler, and how can we represent that on top of the C language? this would not be standard C, by definition, so now we can perform a somewhat apples-to-apples comparison against a language like rust. gccrs is a particularly instructive case study, since its implementation requires exactly such a set of modifications to a generic compiler like gcc.
@rysiek i am aware, and i know that you are aware, that there is a long history of retrofitting safety mechanisms onto C in this fashion. i am only really interested in ones that seek to define generalizable semantics for memory relationships that map to hardware guarantees (i.e. ones which do the same incredibly difficult work that goes into the maintenance of the C abstract machine)—i.e., ones that starkly distinguish primitive constructs enforced by the mid-end and backend from the UX affordances we can provide in the frontend.
@rysiek when rust is effective, it is because of the many years of concerted effort across the compiler to produce language-level abstractions that enable users to manipulate the semantics in their head. lifetimes and the trait model (and the trait model's support for precise and complex abstraction over lifetime bounds) is rust's magnum opus. it was built by people who used C++ to write networking code for a web browser and genuinely believed in user safety and privacy being a function of memory safety.
@rysiek however, i claim that the rest of the language is essentially half-assed. despite the frequent lambasting of the C standard for its insufficiency (some of which was usefully didactic), there is absolutely 100% no attempt to do the same for POSIX i/o. i have rewritten std::{path,fs,io,env} in an attempt to achieve the exact same guarantees rust provides from the frontend down to the backend. i was foiled by POSIX. which has its own version of C's global memory address space by mandating the existence of the global shared memory page cache.
@rysiek i'm sure you recall copy dot fail. i have written what i consider low-level i/o code for years, and that vuln was the first time i had ever heard about the linux page cache. it's not well-known (because the POSIX spec actively obfuscates it), but one of the very few hard requirements that POSIX demands is the immediate global visibility of any write() call (along with an "atomic" ordering which is literally not specified). POSIX describes this in terms of torn writes (which is a userspace i/o semantic), but it then imposes this global (cross-process!!!!) mutable data store in the kernel. this is completely fucked.
@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
