Rust in Linux's Kernel 'is No Longer Experimental' (thenewstack.io) 24
Steven J. Vaughan-Nichols files this report from Tokyo:
At the invitation-only Linux
Kernel Maintainers Summit here, the top Linux maintainers decided, as Jonathan Corbet, Linux kernel developer, put it, "The consensus among the assembled developers is that Rust
in the kernel is no longer experimental — it is now a core part
of the kernel and is here to stay. So the 'experimental' tag
will be coming off." As Linux kernel maintainer Steven Rosted told
me, "There was zero pushback."
This has been a long time coming. This shift caps five years of sometimes-fierce debate over whether the memory-safe language belonged alongside C at the heart of the world's most widely deployed open source operating system... It all began when Alex Gaynor and Geoffrey Thomas at the 2019 Linux Security Summit said that about two-thirds of Linux kernel vulnerabilities come from memory safety issues. Rust, in theory, could avoid these by using Rust's inherently safer application programming interfaces (API)... In those early days, the plan was not to rewrite Linux in Rust; it still isn't, but to adopt it selectively where it can provide the most security benefit without destabilizing mature C code. In short, new drivers, subsystems, and helper libraries would be the first targets...
Despite the fuss, more and more programs were ported to Rust. By April 2025, the Linux kernel contained about 34 million lines of C code, with only 25 thousand lines written in Rust. At the same time, more and more drivers and higher-level utilities were being written in Rust. For instance, the Debian Linux distro developers announced that going forward, Rust would be a required dependency in its foundational Advanced Package Tool (APT).
This change doesn't mean everyone will need to use Rust. C is not going anywhere. Still, as several maintainers told me, they expect to see many more drivers being written in Rust. In particular, Rust looks especially attractive for "leaf" drivers (network, storage, NVMe, etc.), where the Rust-for-Linux bindings expose safe wrappers over kernel C APIs. Nevertheless, for would-be kernel and systems programmers, Rust's new status in Linux hints at a career path that blends deep understanding of C with fluency in Rust's safety guarantees. This combination may define the next generation of low-level development work.
This has been a long time coming. This shift caps five years of sometimes-fierce debate over whether the memory-safe language belonged alongside C at the heart of the world's most widely deployed open source operating system... It all began when Alex Gaynor and Geoffrey Thomas at the 2019 Linux Security Summit said that about two-thirds of Linux kernel vulnerabilities come from memory safety issues. Rust, in theory, could avoid these by using Rust's inherently safer application programming interfaces (API)... In those early days, the plan was not to rewrite Linux in Rust; it still isn't, but to adopt it selectively where it can provide the most security benefit without destabilizing mature C code. In short, new drivers, subsystems, and helper libraries would be the first targets...
Despite the fuss, more and more programs were ported to Rust. By April 2025, the Linux kernel contained about 34 million lines of C code, with only 25 thousand lines written in Rust. At the same time, more and more drivers and higher-level utilities were being written in Rust. For instance, the Debian Linux distro developers announced that going forward, Rust would be a required dependency in its foundational Advanced Package Tool (APT).
This change doesn't mean everyone will need to use Rust. C is not going anywhere. Still, as several maintainers told me, they expect to see many more drivers being written in Rust. In particular, Rust looks especially attractive for "leaf" drivers (network, storage, NVMe, etc.), where the Rust-for-Linux bindings expose safe wrappers over kernel C APIs. Nevertheless, for would-be kernel and systems programmers, Rust's new status in Linux hints at a career path that blends deep understanding of C with fluency in Rust's safety guarantees. This combination may define the next generation of low-level development work.
I have to say by now I approve (Score:4, Interesting)
While the Rust community is certainly toxic in parts, the language has one really big advantage: It is hard to learn!
My take is this does more for security and reliability than all the security features it has, because it keeps the clueless coders (which is the majority) out of it.
Now please fix the one glaring defect Rust has: No spec. And no, do not tell me "the implementation is the spec". That is amateur-hour nonsense.
Re:I have to say by now I approve (Score:5, Insightful)
It may be slightly worse because there's nothing quite so dangerous as someone who believes they're not in any danger because they've got some kind of magic rock. I'll take someone who knows that they're handling something dangerous (bonus if they've got the scars to prove it) and treats it like it's something dangerous. Rust (or any tool for that matter) is of no benefit if it makes the people using it more complacent towards the problems it can't prevent.
Re: (Score:2)
Rust (or any tool for that matter) is of no benefit if it makes the people using it more complacent towards the problems it can't prevent.
I agree on that. But I do not think the tool choice plays a role in whether people take something seriously or not. Some people do understand risk and risk management, but most simply do not and nothing will change that. The benefit of Rust is that it is likely quite a bit harder to learn that C and that selects the people for those that actually want to do this right and are willing to invest significant effort and bring significant talent to the table. And that may make a significant difference. In any ca
Re: (Score:2)
The language itself still can't prevent people from doing stupid things or ensure that they follow best practices as the recent CloudFlare outage showed. [substack.com]
That failure is one of the greatest things about rust. Whoever wrote that code already knew that something could fail, but actively chose to disregard it. It's not like Java or C++ where you do something, and because you didn't read the entire documentation about that library (and that's assuming the developer even documented it, which they often don't) suddenly your code throws an exception at runtime. The developer who wrote that line KNEW it could fail when he wrote that line. Why? Because he HAD to have
Re: (Score:2)
While the Rust community is certainly toxic in parts
Why do you guys keep claiming this? Even before I ever thought of learning rust, I never saw this. Part of the reason I made a sudden switch from making an effort to learn go to learning rust was because every interaction I had with them was really nice. Every one of them have always been willing to go out of their way to explain even basic CS concepts in a non-condescending way in every interaction I've had with them.
Shit, even here I've had to explain CS concepts to people WITH ACTUAL CS DEGREES (which I
Re: (Score:3)
Because this "community" decided to bring their real-world (and non-germane) politics into the project from day one. Not something you ever saw with C.
Re: (Score:2)
God forbid anyone ban bullying at a time when bullying was becoming increasingly common in tech communities.
I'm not sure how it qualifies as "toxic" to ban toxic behavior, but there we go. In the mean time at least one kernel programmer has been celebrated here for actively lying about the Rust project and demanding the Rust modules be banned from using his code because... no reasons given.
Literally the only reason for objecting to Rust's "real world politics" is if you wanted to call a fellow programmer wh
Re: (Score:2)
How? And when?
If you're talking about that deutschbag who believed social media shaming others into bending to your will is the correct way to get your point across, he already blew a headgasket and left after he didn't get his way. Besides, that's not a typical rust user, that's a typical internet german, and he isn't even the first internet german linux kernel developer to do that. And it even extends to non-internet germans to a degree, see for example the raids they've been conducting in their country a
Re: (Score:2)
While the Rust community is certainly toxic in parts
Why do you guys keep claiming this?
Observable evidence. I guess you are unfamiliar with the concept?
Re: (Score:2)
Actually a lot of research has been done on this, by google, amazon, microsoft, and many others,
Oh, look, somebody needed "research" to justify their management decisions ...
Re: (Score:2)
Makes no sense (Score:2)
Rust's new status in Linux hints at a career path that blends deep understanding of C with fluency in Rust's safety guarantees.
It would seem that adopting Rust, which is supposed to be safe by design, would relieve developers of the duty to write safe code. After all, its Rust. None of these nasty null pointers and buffer oveflows are possible. Just like Python relieves developers from the duty of formatting readable code.
Developers should now be freed to make higher level, more difficult to find logic erors.
Re: (Score:2)
It would seem that adopting Rust, which is supposed to be safe by design, would relieve developers of the duty to write safe code.
It very much does not. And Rust is not "safe by design" either, that is nonsense. It can prevent or reduce some forms of problems, mostly from the areas of memory safety and effects like race-conditions. But look at PHP, which is completely memory safe and still one of the worst source of security problems.
What Rust does is to allow actually competent secure code developers to focus more on the remaining problems, of which there are many.
What Rust lacks to be taken fully serious is a specification. No, an i
Re: (Score:2)
In fairness, PHP simply replaces one type of lack-of-safety with another. C does not assume null, 0, "", "0", and false or all the same thing, something PHP does because... reasons. If PHP actually implemented mandatory type safety, PHP would be no worse than Python, and the rewritten code running under the new PHP would have most of the security issues fixed.
Rust's spec... do bear in mind there's at least one project out there that's implementing an independent version of Rust. You kind of need multiple im
Re: (Score:2)
I'm always baffled by the insistence of Rust, Java, or other modern programming languages that developers can only make a certain number of errors-per-project. That somehow if you write something in C it'll be perfect except for the buffer overflows and null pointers. That if you write it in Java or Rust or Go or whatever somehow those will go so you need to introduce logic errors instead.
Is this how you program?
As for "Developers should now be freed to make higher level, more difficult to find logic erors"
Re: (Score:2)
Developers should now be freed to make higher level, more difficult to find logic erors.
Rust helps prevent that as well, and a great deal at that. I found a good writeup here:
https://itsallaboutthebit.com/... [itsallaboutthebit.com]
Also, a concept I commonly apply in rust, which generally isn't possible to do in most languages:
https://medium.com/@lucky_ryda... [medium.com]
Designing your data structures in such a way that you literally can't accidentally create an invalid state is a godsend. I don't care how good of an engineer you are, you'll inevitably forget to check some odd thing here or there that results in a subtle bug som
Is there an engineering reason why... (Score:2)
Re: (Score:2)
Marketing. There is no sane reason to reimplement things in Rust, unless they have been a constant security problem. For example, reimplementing Bind would probably a good idea with their constant crap. But you can just move to alternatives. Same for Sendmail, but Postfix is an excellent replacement.
Reimplementing commandline-tools that are not a problem is pure insanity.
Re: (Score:2)
Usually people leave the old code intact. However, here's a great example for why you might rewrite it:
https://blog.reverberate.org/2... [reverberate.org]
Re: (Score:2)
Are the people rewriting everything in Rust with us in the room right now?
There are some projects to rewrite some tools in Rust, sometimes unnecessarily, but nobody's proposed rewriting everything or even everything in use. Even this article is about Rust being added to the kernel, not rewritten in it. Where are you getting it from that, say, anyone is proposing rewriting the Linux kernel in Rust?
Re: (Score:2)
2. Projects evolve as they're implemented and many developers have a list of things they would have done differently if they knew ahead of time how the project would end up. If someone chooses to rewrite their project based on lessons learned, why not choose a language that has similar performance
Just don't require it (Score:2)
I'm OK with people having rust modules and the like but I don't want it to become part of the core kernel because if it does...
1) It may negatively impact several platforms because the Rust toolchain is only fully supported on ARM64, i686, and x86_64. [rust-lang.org]
2) It will require multiple multiple toolchains just to build the kernel which will significantly raise the requirements for bootstrapping.
3) SIGNIFICANTLY raises the difficulty to port Linux to a new architecture. Making GCC for a new target is bad enough, con
Linux Rust-C transpiler needed (Score:2)
If people want to use Rust (technically "Linux Rust") in the Linux kernel, that's OK. However, requiring two toolchains to compile the kernel is a roadblock for platforms that are not fully supported, let alone new unsupported platforms. The logical answer is to make a Linux Rust to C transpiler which would enable code development in Rust while ensuring 100% compatibility with poorly supported and unsupported platforms.