Rust Will Save Linux From AI, Says Greg Kroah-Hartman 29
Linux stable kernel maintainer Greg Kroah-Hartman says Rust can help Linux deal with a flood of AI-discovered security bugs (namely Dirty Frag, Copy Fail, and Fragnesia) by preventing common C mistakes around memory, locking, error handling, and untrusted data at build time rather than during human review. It's "not a silver bullet" and does not mean rewriting the whole kernel, but he said new drivers and subsystems will increasingly use Rust as Linux evolves forward. ZDNet reports: Kroah-Hartman illustrated those pitfalls with real C bugs in the kernel, including a 15-year-old Bluetooth bug that dereferenced a pointer without checking it and a Xen bug where "we forgot to unlock" in an error path. "The majority of the bugs in the kernel are this tiny, minor stuff," he explained. "Error conditions aren't checked, locks aren't forgotten, unreleased memories leak, and vulnerabilities add up over time. They crash the kernel. This is what we live with in C. This is why we don't like it." Kroah-Hartman argued that the "best beauty of Rust" is catching those mistakes at build time rather than in review. For example, when it comes to locking, he highlighted Rust's locking abstractions in the kernel: "The only way you can get access to inner pointers of structures is by grabbing that lock, and releasing the lock automatically. The compiler does it, it's guarded, the lock happens, everything's happy. You just can't write code to access these values...without grabbing the lock. The compiler will not let you."
Those properties, he argued, directly remove a huge fraction of the bugs he sees: "This is going to save us those two things. First, 60% of the bugs in the kernel right there, they're gone. Thank you." The payoff is earlier, more automated enforcement: "If this happens at build time, not review time, don't make me a maintainer who has to read your code [and] say, 'Oh, then you properly check that error value. Oh, did you properly grab the locks in the right spot?' Rust gives us that for free. This is the best thing ever." Even if Rust vanished tomorrow, Kroah-Hartman argued, it has already forced the kernel to clean up C code and interfaces. He credited Rust's influence outright: "We stole this from Rust. Thank you. It's a good idea, so if Rust disappeared tomorrow, we have cleaned up the C code in the kernel so much and taken in the ideas. We thank you, you've made Linux better with it just by existing."
[...] What ultimately sold a number of core maintainers, including him, on Rust was how it "makes reviewing code easier." With CI [Continuous Integration] bots enforcing builds and Rust's type system enforcing key invariants, maintainers can "focus on the logic" rather than resource bookkeeping: "I can care about that one function. I don't have to worry about the rest of this stuff, because I assume that it works properly, because it was built properly." Internally, he said, the top maintainers have already made their call on Rust's status: "The Linux kernel maintainers, we get together every year and talk about what the processes are doing. Last year, we said the Rust experiment is over. It's not an experiment. This is for real." The rationale: "The people behind it are real. We trust them. We know what they're doing. They've shown and put in the work to make Rust a viable language in the kernel, and we're going to make this stick. Let's go full speed ahead. And, as always," he said wryly, "world domination proceeds." "If you never remember anything else in my talk, just remember these four words. It came from Microsoft Security many, many years ago," Kroah-Hartman told attendees. "They realized all input is evil. You have to validate all input."
Those properties, he argued, directly remove a huge fraction of the bugs he sees: "This is going to save us those two things. First, 60% of the bugs in the kernel right there, they're gone. Thank you." The payoff is earlier, more automated enforcement: "If this happens at build time, not review time, don't make me a maintainer who has to read your code [and] say, 'Oh, then you properly check that error value. Oh, did you properly grab the locks in the right spot?' Rust gives us that for free. This is the best thing ever." Even if Rust vanished tomorrow, Kroah-Hartman argued, it has already forced the kernel to clean up C code and interfaces. He credited Rust's influence outright: "We stole this from Rust. Thank you. It's a good idea, so if Rust disappeared tomorrow, we have cleaned up the C code in the kernel so much and taken in the ideas. We thank you, you've made Linux better with it just by existing."
[...] What ultimately sold a number of core maintainers, including him, on Rust was how it "makes reviewing code easier." With CI [Continuous Integration] bots enforcing builds and Rust's type system enforcing key invariants, maintainers can "focus on the logic" rather than resource bookkeeping: "I can care about that one function. I don't have to worry about the rest of this stuff, because I assume that it works properly, because it was built properly." Internally, he said, the top maintainers have already made their call on Rust's status: "The Linux kernel maintainers, we get together every year and talk about what the processes are doing. Last year, we said the Rust experiment is over. It's not an experiment. This is for real." The rationale: "The people behind it are real. We trust them. We know what they're doing. They've shown and put in the work to make Rust a viable language in the kernel, and we're going to make this stick. Let's go full speed ahead. And, as always," he said wryly, "world domination proceeds." "If you never remember anything else in my talk, just remember these four words. It came from Microsoft Security many, many years ago," Kroah-Hartman told attendees. "They realized all input is evil. You have to validate all input."
Re: (Score:2)
Just to point it out, in case people drink the kool-aid.
Just be cause "Rust does this thing better" does not mean you should always use Rust instead of C. You should always be using C when performance matters. Not Rust, not C++. If anything, C developers should be always using /Wall or /W4 and then treat all warnings as errors with /Werror . Many MANY projects out there have thousands of warnings a lot of then dealing with uninitialized memory, integer/floating point casts, and string lengths.
Realistically,
Re: (Score:2)
Even if Rust vanished tomorrow, Kroah-Hartman argued, it has already forced the kernel to clean up C code and interfaces. He credited Rust's influence outright: "We stole this from Rust. Thank you. It's a good idea, so if Rust disappeared tomorrow, we have cleaned up the C code in the kernel so much and taken in the ideas.
The problem is he had never put much thought into how to actually manage memory in a reasonable way in C. This is why C code is bad, because C programmers never ask themselves, "How do I not leak memory?"
Wait, 4 words? (Score:3)
"If you never remember anything else in my talk, just remember these four words. It came from Microsoft Security many, many years ago," Kroah-Hartman told attendees. "They realized all input is evil. You have to validate all input."
Which four words are we supposed to remember?
Re: (Score:2)
"All input is evil"
Re: (Score:2)
"All input is evil"
It was a slide he displayed around 27m 20s in his talk before the RustNL group
Re: (Score:1)
Somebody forgot to validate the word-count
embarrassing what qualifies as a programmer (Score:2)
"This is what we live with in C. This is why we don't like it."
It is not, it's what is lived with in a codebase, C has nothing to do with it. Also, there is nothing about an approach mandated by one language that cannot be implemented in C, Rust creators have not made anything that kernel developers cannot otherwise do.
It is sad what programmers have become that cause claims like this to be made.
"With CI [Continuous Integration] bots enforcing builds ..."
The battle is already lost.
"They realized all input
Re: (Score:2)
"what he is alleged to do"
WTF? that's like saying Linux is "alleged" to have been named after Linus Torvalds
Re: (Score:2)
Well done, sir.
Re: (Score:3)
It is not, it's what is lived with in a codebase, C has nothing to do with it. Also, there is nothing about an approach mandated by one language that cannot be implemented in C, Rust creators have not made anything that kernel developers cannot otherwise do.
C has everything to do with it. C requires that programmers be infallible. They're not. They never have been. They never will be.
Rust's designers understand that programmers are human and will always make mistakes so the language allows and even requires building safe zero-cost abstractions that allow the compiler to check for huge swathes of common mistakes. Rust isn't the first language to do that, by any means, but it's the first language that (a) does it consistently and thoroughly (C++ fails this
Re: (Score:3)
The reason is that even though he has been programming in C for 20 years or more in the kernel, he never sat down and asked himself, "How do I avoid memory bugs in C? How do I avoid bugs?" It wasn't until he started using Rust that he even began approaching that question.
So his code is going to have plenty of other bugs, simply because he's never asked himself the question, "How do I avoid bugs?" No language is going to save him.
What's the benefit of Rust here though? (Score:2)
If you've got the AI tools to tell you how you screwed up with C, why do you need Rust? Just fix what the LLM says you broke. Now you have the speed of C without the bugs. It ought to be easy to find that class of error, right?
Re: (Score:2)
Better yet, the LLM can just write the secure C code in the first place.
If Mythos is so great, why not close the loop?
Re: (Score:2)
The problem is that time between the AI tool discovering a bug and the release of the patch, there's a bunch of panicked work by the developers and a time where the vulnerability is exploitable without an available patch. So if they can avoid several classes of errors and those are most of what the AI are finding, there's a bunch of work saved.
If it was just the developers using the AI tools though and the patch notes weren't open, then you'd more correct.
Re: (Score:1)
Re: (Score:2)
For existing code in the QA he said leave it be and it's better to fix.
For new code, he's recommending Rust and the advantage he talks about is that it makes the code more maintainable by people. And one thing that every AI coding talk I've seen agrees on is that what makes code more maintainable by people also helps AI and vice versa.
People and AI both have limited attention and memory. The less context necessary the easier it is to evaluate safety.
Another thing not in the summary he touches on is hardwa
Rust Can't Even Save Linux from Vulnerabilities (Score:2)
Re: (Score:2)
That being said, LinuxBugs - CMemBugs + RustBugs < LinuxBugs.
Re: (Score:2)
As always (Score:2)
Everything decays to Rust [9cache.com].
Other quotes from talk. (Score:2)
To balance out OP's selective quoting to avoid people strawman-ing his argument as a fanatic who can't balance risk:
"No, we don't want [rust] rewrites, so unless you're the maintainer and owner of that file, just do it for new stuff. Leave existing C code alone, and let's evolve forward after that."
Now, that doesn't mean he thinks Rust is magic. It's not. He cited one of the first Rust components merged into the kernel: QR code display logic used when the kernel crashes. "That logic was written in Rust. Famously, it had a memory bug. It was given a buffer and its size, and the rest of the st code never checked the buffer size... Could scribble all over memory..."
Rust? Can't spell LLVM without LLM (Score:2)
Before Rust can save Linux from AI, wouldn't someone need to save Rust from AI first? The Open Slopware [codeberg.org] page claims that LLVM's LLM policy requiring a human in the loop [codeberg.org] is overly permissive.
Expected article in 3..2..1.. (Score:1)
"AI will save Linux from Rust"