Rust in Linux's Kernel 'is No Longer Experimental' (thenewstack.io) 86
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:5, 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:I have to say by now I approve (Score:4, Interesting)
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 case, I do not think it will make things worse. But we will find out.
Re: (Score:3)
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:3)
If you can write it with an efficient run time in Rust without using the "unsafe" keyword and without relying on a library that uses the "unsafe" keyword then you've generally identified a use case where Rust is a better choice than C. If you need the "unsafe" keyword or have to write convoluted code to work around its absence, C is likely still a better choice. The kernel has both use cases.
Re: (Score:2)
If you need the "unsafe" keyword or have to write convoluted code to work around its absence, C is likely still a better choice.
Maybe you could argue C++ here but C? No.
Doing a ton of stuff by hand when it can be easily automated seems to me to be a terrible choice. Even simply using a more expressive language over C, with a richer type system to express programmer intent and good facilities for error free generation of repetitive code is a better choice.
And secondly, the argument doesn't even hold up on it
Re: (Score:2)
I have to disagree. There is nothing bad about(or worse) about using "unsafe" in Rust compared to say C. It only indicates small areas of code that the programmer has to pay attention to as certain checks the compiler makes are disabled. That is already a huge advantage as now there is a huge lot of checks in the rest of the code that the programmer no longer needs to worry about.
I would agree if all the code in ones Rust program were "unsafe". That is really the case and expect it need not be true for most
Re: (Score:2)
C is not that hard once you realize the relationship between C and the ASM/Machine code. C is just a structured form of ASM, and the compiler has to do the optimization at compile time.
Assembly language is incredibly unparseable. It's actually amazing that every game for 8-bit and 16-bit game consoles was assembly language.
Certain programming languages make sense for certain tasks. Most GUI driven software is difficult to understand without an object-representation of the GUI objects, which is why C++ makes
Re: (Score:2)
Re: (Score:2)
The problem is kernel code IS hard. The Linux kernel code uses a lot of fancy tricks to make it a lot easier. But there are still a lot of places where it remains tricky.
If you've coded for Linux kernel for decades, it used to be you needed to know your context - atomic or process. But over the decades, the need to know this died out - very little code is still atomic and most developers which would've needed to care, don't anymore.
But other parts are no so forgiving - because kernel code is naturally re-en
Re: (Score:2)
According to Netflix dev Primagen the real issue was that the FL1 code was in Lua
https://www.youtube.com/watch?... [youtube.com]
Re: (Score:3, Interesting)
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)
If you're bringing any of this into a forum that is exclusively about programming, then 100% you're doing it wrong. I don't care whether you are in favor of it or entirely against it.
Sites like this it's fine, because this site explicitly includes such topics. This is why I openly shit on rsilvergun and drinkypoop here, even though IRL I really have nothing to say to communofascists like them.
Re: (Score:2)
No one asks that you call a man in a dress a woman. It's not the dress that is the deciding factor. The problem is that there are a pile of woman traits and a pile of man traits, and they aren't always grouped together. And you do get people that are mostly woman traits except for those few physical male traits, or all male traits except for those few physical female traits. The rounding error should not go to the minority physical traits -- not even when those minority parts are the most visible parts. Thu
Re: (Score:1)
Lies out of the gate. Subjective vs Objective reality. Subjective loses.
Re: (Score:2)
Those who refuse to recognize that sex (not gender but yes actual sex) is a spectrum of traits have failed the test of objective reality.
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)
Did they? I have been a member of the Rust user forums for six years now and almost never has any political discussion been seen.
Sure they have a dozy Code of Conduct or whatever, but that is everywhere now a days. And I don't think that is necessarily a bad thing.
Re: (Score:1)
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:3)
I see you're totally unfamiliar with this concept:
https://en.wikipedia.org/wiki/... [wikipedia.org]
And no, what you're doing is not empiricism. See also: The plural of anecdote is not data.
Re: (Score:2)
You wish. Well, an idiot is somebody that does like an idiot. You just nicely demonstrated that concept.
Re: (Score:2)
Indeed, I plainly showed that you are doing idiotic things.
Re: (Score:1)
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)
And what's wrong with that?
Re: (Score:2)
Is this a serious question?
Re: (Score:2)
Considering you're trying to imply that research should never guide management decisions, yeah.
Re: (Score:2)
I am not implying that. You completely missed what I was actually implying. I guess you have never heard of bought research.
Re: I have to say by now I approve (Score:2)
Oh, I see, you're a conspiracy theorist. Indeed, you truly are an idiot. You're trying to compete with rsilvergun for moron of the decade, aren't you?
Re: (Score:2)
What do you mean. We always complain about "stupid management". Should you not be pleased that at least sometimes management checks actual reality before proceeding?
Re: (Score:3, Insightful)
Re: (Score:3)
That's what I feel about C, the language is simple and the pitfalls are very known, how difficult can it be?
But humans are lazy even though they apparently like shiny new complexity, don't want to double-check and take responsibility, actually be competent at their chose profession. Any profession.
Re: (Score:2)
It seems that it would just be easier to learn what not to do in c than to learn a whole other language.
Literally no one has ever managed to learn what not to do in C to a level that prevents security problems. That's one of the fundamental problems with humans, they make mistakes. That is evident in literally every level of programmer on the planet.
See also: The reason we put airbags in cars rather than trying to teach better driving.
Every day I'm a little more convinced you are either a robot or an alien.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
I do no think this true. There C projects with good security track record and it is also relatively well understood how to do it. My number one recommendation is to not do open-coded buffer or string manipulation by using pointer arithmetic. This simple to do but almost all of C OOB issues I see are caused by this. Nobody tells that it need an inhuman level of engineering to put these behind safe accessor functions. Where Rust has a real advantage is temporal memory safety (use-after-free), but here are c
Re: (Score:2)
My number one recommendation is to not do open-coded buffer or string manipulation by using pointer arithmetic. This simple to do but almost all of C OOB issues I see are caused by this.
Maybe this is a stupid question, but is it a problem with using pointer arithmetic, a problem of not ensuring you do proper bounds checking (even having a maximum boundary for instance), and the like, or even both?
Re: (Score:2)
Literally no one has ever managed to learn what not to do in C to a level that prevents security problems.
This is not, strictly speaking, true. We have learned how to write C in a way guaranteed to prevent security problems. Turns out it's really, really hard https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
I agree. People should learn what not to do in C. Every C programmer does, for the most part, eventually.
The next step is to think "I don't want to waste my time doing all that endless checking, reviewing and debugging of my code. It's boring, tedious, error prone and a wast of my time."
Then the light goes on "Wouldn't it be great if we invented a language, largely like C, where it is possible to automate all that boring "busy work".
What is not to want about that?
You make it sound like learning a new langua
Re: (Score:2)
Re: (Score:2)
Language difficulty is no object in the age of AI.
Re: (Score:2)
Why do you feel the need to say "While the Rust community is certainly toxic in parts... "? As if that was a property of the Rust community and no other. It's absurd. I have been using Rust for six years now and hence interacting with many Rust devs and users and following Rust discussions, I rarely see anything "toxic" going on.
Sure Rust is challenging to learn. But then so is C++. C is simpler but getting stuff to work correctly in C is therefore more difficult. Becoming familiar with all the weirdness of
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:Makes no sense (Score:5, Insightful)
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 implementation can never replace a specification, that idea is amateur-level.
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)
The spec is not for competing implementations. The spec is for assuring properties of code. Something critically important in secure coding. Yes, many people do not understand that, but most people do not understand what secure coding actually means. Yes, the implementation may still have bugs, but with a spec you can reliably find out whether something is a bug or not.
Re: (Score:1)
with a spec you can reliably find out whether something is a bug or not.
Unless it's a bug in the spec.
Unlike an implementation, you can't test a spec. The only way to truly validate a spec is to have an implementation. And the only way to truly trust a spec is to have multiple implementations.
Most of the new features in GCC/Clang are first implemented in the compilers, in experimental branches and/or forks, to ensure that the feature actually works as intended and as expected. Then they write a spec for them.
And a lot of the new C++ library features come from other existing lib
Re: (Score:3)
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)
> I'm always baffled by the insistence of Rust, Java, or other modern programming languages
should be
> I'm always baffled by the insistence by opponents of Rust, Java, or other modern programming languages
This has been your reminder that Slashdot's refusal to allow people to edit their own comments just generates more heat than light.
Re: (Score:3)
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:3)
Re: (Score:1)
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:3)
The unknown risk is a reason to rewrite when that risk outweighs the risk of the rewrite. When we do not know whether there's a memory problem or not in codebase A, but the codebase was developed using the same techniques as codebase B that has memory problems, we can make an educated guess that codebase A also has problems. If codebase A is critically important, it may be worth the refactoring risk to rewrite into a language where we can prove many classes of memory faults cannot exist.
Re: (Score:2)
That is complete nonsense. The new implementation will have bugs as well. And because it is far less mature, they will be worse.
Re: Is there an engineering reason why... (Score:3)
Depends on the quality of your test suite and the quality of your software engineering team and whether you are dedicated to only rewriting not rewriting and adding functionality simultaneously. I have been part of many rewrites that have been far less buggy than the originals. In the case of driver software, the functionality is often extremely narrowly scoped, which makes the goal far more achievable.
Re: (Score:2)
No. Not in this case.
Re: (Score:2)
Ubuntu shipped the coreutils rewritten in Rust which had a lot of quality issues which broke automatic upates. Broken automatic updates is a hell lot more serious in terms of security impact than memory safety issues found in C code (which may not always be exploitable and / or often also irrelevant).
Re: (Score:2)
I did not say everything was a good candidate. You asked if there was ever a sane reason. Yes. And I have been a part of successful rewrites of working code to address unknown issues. You have to have an excellent test suite and a really dedicated team with some very high ceremony dev processes. It is slow and expensive. Excruciatingly slow. My estimate is 5x dev time of the original development. The security risk has to be worth that level of investment. If it isn't, then it isn't worth it. But there are c
Re: (Score:2)
I agree there might be cases for rewriting things (it wasn't me who asked). But no recent Rust rewrite I have seen in the open-source world made any sense to me.
Re: (Score:2)
Sorry about the "you"... I confused which screen name I was replying to. :-)
Re: (Score:3)
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:3)
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:Is there an engineering reason why... (Score:5, Informative)
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, a more modern technology stack and set of tools, and prevents all contributors from making foolish mistakes?
3. Rust is already fairly popular and seems to be growing in popularity. It may be easier to find contributors and maintainers for a project in Rust in a decade or so, which helps the longevity of the project.
Re: (Score:2)
Reasons for rewriting:
Option 1: We know the old stuff is riddled with memory insecurites.
Option 2: We do not know the old stuff is riddled with memory insecurities, but it looks a whole lot like code that we know fits Option 1.
By rewriting in Rust, particularly if we have a solid test bed to ensure that the functionality stays the same, we can eliminate proactively a class of bugs that is among the most destructive to the software environment. While a logic bug makes a program go off the rails and may cause
Re: (Score:2)
After years of using Rust and interact with Rust people I have pretty much never heard any feverishly campaigning to rewrite every thing in Rust. Where do you get that over generalisation from.
Sure the are such cases. Typically they have very good reasons for a reimplementation other than just "Ooo Rust".
Just don't require it (Score:3, Informative)
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, consider if you have to also make a new target for Rust before you can even get Linux to boot.
So, celebrate all you want, just don't break working platforms, or hinder new platforms because of an ideological desire to use Rust.
Re: Just don't require it (Score:2, Flamebait)
You're making the mistake of thinking New Shiny zealots give a shit about portability. All they care about is winning their moronic argument.
Re: (Score:2)
You're making the mistake of thinking New Shiny zealots give a shit about portability. All they care about is winning their moronic argument.
I've heard Linus called a lot of things, but this is a new one to me. Why do you hate Linux's creator so much?
Re: (Score:2)
Once gccrs is here, the problem is easier. GCC 16.1 is the target to compile actual code, and start catching up with the rust version used in the kernel. So mostly within a year, the problem you mention solves itself. Source: status report for rust-for-linux https://rust-for-linux.com/gcc... [rust-for-linux.com] and Rust-GCC https://github.com/Rust-GCC/Re... [github.com]
Linux Rust-C transpiler needed (Score:5, Insightful)
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.
Re: (Score:2)
Rustscript! (ducks)
Someone with one watch... (Score:1)
The telling part... (Score:2)
"There was zero pushback."
Bullshit. There is always pushback against anything new and different, so this very statement is marketing nonsense. We all know people are sharply divided about things like Rust, systemd, and Wayland.
There is still no spec, and to use anything without a formal spec as part of a mission-critical project like an OS kernel is terribly irresponsible. There was pushback and it was going on for years. It was simply ignored.
Yet another great indicator why Linux continues its struggle to take over the desktop.