Rust Will Save Linux From AI, Says Greg Kroah-Hartman 43
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:I don't currently use Rust (Score:4, Insightful)
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, string handling sucks in C because of the baggage of ANSI C, as wchar_t makes things horrible to debug.
The thing that would make C/C++ code safer from the start to implicitly check the length of variables, instead of having to pass the length.
All post-unicode languages such as Rust, Javascript and Python (not PHP or Perl) handle their strings internally as unicode, thus you don't actually need to know the length of the string to pass to it. In C is a UTF-8 string have a BOM? Does it use Windows, Mac or Unix line endings? you have up to three additional non-printable characters when dealing with unicode. Then there is Windows which is an additional special hell because it's wchar_t is UTF-16 in visual C but UTF-32 in GCC. Yet the vast majority of software out there only wants to deal with UTF-8.
If C and C++ natively did UTF-8, a good chunk of mistakes would not happen. Pointer nonsense not withstanding, most of the mistakes in C could probably be tracked by an AI linter and OSS projects could just fix things instead of publishing code that would fall under treating all warnings as errors. It's the pointer stuff that trips up people who don't understand the underlying assembly language code it would make. So people not familiar with C or ASM will constantly use variables that use the local registers rather than the ram address, and then wonder why the compiler complains about stack space.
Fun fact "the switch" statement is a heavy use of the stack space, because the compiler is unwrapping this to a series of "jump if equal" which is equal to "if" statements. This is the purpose of making functions as small and single-purpose as possible and antithesis of C++ classes. This is why you don't use C++ in performance code.
Rust seems to aim to be "better C" but doesn't necessarily do so since it technically runs on the C runtime. I think Rust might be fine to use in things outside of kernel space, but it seems like it might be expensive to use in the kernel/driver space.
Meanwhile, Nvidia, AMD, Razer, and Logitech are out there making "Driver" bundles that are full on chromium embedded frameworks , going in much the wrong direction. These companies have stopped caring.
Re: (Score:1)
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?"
Re: (Score:2, Insightful)
This is why C code is bad, because C programmers never ask themselves, "How do I not leak memory?
WTH sort of C programmers have you been talking to? Yeah, you should get those guys on Rust as soon as possible.
Re: (Score:2)
This is why C code is bad, because C programmers never ask themselves, "How do I not leak memory?"
Another way to phrase that would be, "This is why C code is bad, because C programmers are expected to understand the rules about how to not leak memory, but there is no mechanism to enforce that requirement".
Wait, 4 words? (Score:4, Insightful)
"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:Wait, 4 words? (Score:4, Informative)
"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: Wait, 4 words? (Score:2)
Re: (Score:2)
Somebody forgot to validate the word-count
Re: (Score:2)
All Input Is Evil
embarrassing what qualifies as a programmer (Score:3)
"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 is evil. You have to validate all input."
No. Depends on where the input comes from. Hard to have respect for this guy, regardless of what he is alleged to do.
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:1)
Well done, sir.
Re: (Score:2, Insightful)
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.
Re: (Score:1)
Re: embarrassing what qualifies as a programmer (Score:2)
Re: (Score:3)
You know what improves code quality? Process improvements.
You know what doesn't improve code quality? Telling people that they suck. It's pointless and immature.
Re: (Score:2)
While he's written a fair bit of code, he's mostly been a maintainer for a long time.
There are ~5000 Linux kernel devs representing over 300 corporations.
Do they all suck as much as GKH? Then why would anyone adopt Linux?
Hint: Linux world domination happened quite some time ago.
What's the benefit of Rust here though? (Score:5, Insightful)
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
Re: (Score:2)
If you have access to a God-tier LLM that you can rely on to find every bug, I think that could work.
However, I don't think anyone in the Linux community is ready to trust LLMs to that extent just yet. Not only are they quite fallible, they are also non-deterministic -- so if you ask your favorite LLM to find the bugs in the code, and it doesn't find any, and then you feed it the exact same prompt again, it might find some on its second attempt. So how do you know when to stop re-asking?
LLMs are currently
Rust Can't Even Save Linux from Vulnerabilities (Score:2)
Re: (Score:2)
That being said, LinuxBugs - CMemBugs + RustBugs < LinuxBugs.
Re: (Score:2)
Re: Rust Can't Even Save Linux from Vulnerabilitie (Score:3)
As always (Score:2)
Everything decays to Rust [9cache.com].
Re: (Score:2)
if any of the other programming languages were good enough, the Law of Rustification would not exist.
that said, Zig apparently is showing great potential as a Rust alternative but still some way distant from a 1.0 release
Other quotes from talk. (Score:3)
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:2)
"AI will save Linux from Rust"
Rust really does make a difference (Score:2)
After doing some heavy low-level C coding for many years, I recently decided to look at Rust and see what it's all about. It really is a huge improvement over C.
With C, you need to understand the capabilities of the hardware and low-level operating system features. Shared memory, locks, semaphores, basic memory management, and, of course, pointers for everything.
With Rust, a deeper understanding of how the OS works really helps. The heap and stack for function calls and passing parameters, concurrency, a
Rust will bring world peace (Score:4, Funny)
We should allow for programming languages to be awarded the Nobel Peace Price.
If Henry Kissinger can get a Nobel Peace Price, Rust should also be able to get one because everything is better with Rust.
I'd wish that someone would have pointer out that Visual Basic doesn't have pointers so we could have had Linux kernel support for it.