>Bergmann agreed with declaring the experiment over, worrying only that Rust still "doesn't work on architectures that nobody uses".
I love you Arnd.
More seriously, this will become an issue when someone starts the process of integrating Rust code into a core subsystem. I wonder whether this will lead to the kernel dropping support for some architectures, or to Rust doing the necessary work. Probably a bit of both.
There are two separate ongoing projects to make a rust compiler that uses GCC as a backend (one on the gcc side adding a c++ frontend that directly reads rust, one on the rustc side to make rustc emit an intermediate format that gcc can ingest).
The long-term solution is for either of those to mature to the point where there is rust support everywhere that gcc supports.
I wonder how good a LLVM backend for these rare architectures would have to be for that to be “good enough” for the kernel team. Obviously correctness should be non-negotiable, but how important is it that the generated e.g. Alpha code is performant for somebody’s hobby?
I suspect more the latter than anything. It could be that by the time Rust gets used in the kernel core, one or both of the GCC implementations would be functional enough to compile the kernel.
I'm curious though, if someone has an ancient/niche architecture, what's the benefit of wanting newer kernels to the point where it'd be a concern for development?
I presume that outside of devices and drivers, there's little to no new developments in those architectures. In which case, why don't the users/maintainers of those archs use a pre-6.1 kernel (IIRC when Rust was introduced) and backport what they need?
No one is doing any kind of serious computing on 30 year old CPUs. But the point of the hobby isn’t turning on the computer and doing nothing with it. The hobby is putting together all the pieces you need to turn it on, turning it on and then doing nothing with it.
There’s an asymmetry in what the retro computing enthusiasts are asking for and the amount of effort they’re willing to put in. This niche hobby benefits from the free labour of open source maintaining support for their old architectures. If the maintainers propose dropping support because of the cost of maintenance the hobbyists rarely step up. Instead they make it seem like the maintainers are the bad guys doing a reprehensible thing.
You propose they get their hands dirty and cherry pick changes from newer kernels. But they don’t want to put in effort like that. And they might just feel happier that they’re using the “real” latest kernel.
> To me the more salient questions are how long before (a) we get Rust in a core subsystem (thus making Rust truly _required_ instead of "optional unless you have hardware foo"), and (b) requiring Rust for _all_ new code.
Previously, the position was that C developers would not be forced to learn Rust.
And a few days ago a security vulnerability was found in the Rust Linux kernel code.
Where did anyone promise that the Rust bits will never have security issues? That CVE was a fantastic demonstration of just how much better the situation is in Rust code and I don't think there's a realistic argument that the experiment has been anything other than successful.
This is certainly not true. But also arguments about "common" are completely misleading as long as there is many orders of magnitude more C code than Rust code.
Maybe you haven't been paying much attention in this space. Google found empirically that error density in _unsafe_ Rust is still much lower than in C/C++. And only a small portion of code is unsafe. So per LOC Rust has orders of magnitudes fewer errors than C/C++ in real world Android development. And these are not small sample sizes. By now more code is being written in Rust than C++ at Google:
But don't take my word for it, you can hear about the benefits of Rust directly from GKH:
www.youtube.com/watch?v=HX0GH-YJbGw
There really isn't a good faith argument here. You can make mistakes in Rust? No one denies that. There is more C code so of course there are more mistakes in C code than in Rust? Complete red herring.
Perhaps because qmail is an anomaly, not Android? To remain relatively bug-free, a sizeable C project seems to require a small team and iron discipline. Unix MTAs are actually pretty good examples. With qmail, for a long time, it was just DJB. Postfix has also fared well, and (AFAIK) has a very small team. Both have been architected to religiously check error conditions and avoid the standard library for structure manipulation.
Android is probably more representative of large C (or C++) projects one may encounter in the wild.
If you are not intellectually capable of following an argument about selective samples (there are C code bases with virtually no bugs), perhaps you should refrain from commenting.
But you know that the mob voting will back you up.
So you can't, and if a "dumbass" like me can understand the importance of empirical evidence but you can't, maybe read up on rational thinking instead of lashing out emotionally.
That is is undefined behavior does not mean it is exploitable. But I also have not seen an argument why a data race should not be exploitable in this context.
I am very wary of going that route. If there is undefined behavior, the compiler is in principle allowed to do anything and everything, unless it promises something beyond what the language promises.
One could then argue that a specific version of a specific compiler with specific settings in a specific case, after investigation of the generated assembly or inspection of what guarantees the compiler provides beyond the language, is not exploitable. But other settings of the compiler and other versions of the compiler and other compilers may have different guarantees and generation of assembly.
The Linux kernel uses, as I understand it, a flag for GCC for C code that disables strict aliasing. That basically means that strict aliasing is no longer undefined behavior, as long as that flag is used. Basically a dialect of C.
It is very common for C implementation to define undefined behavior and also common for C programs to rely on this. For this reason, I think it is very misleading to say that undefined behavior is automatically exploitable or even a bug.
Language-UB (L-UB): UB according to the guarantees of the language.
Project-compiler-UB (PC-UB): The project picks compilers and compiler settings to create a stronger set of guarantees, that turns some language-UB into not being UB. Examples include turning off the strict aliasing requirement in the used compilers, or a compiler by default defining some language-UB as being defined behavior.
I do not know if such terms might catch on, though. Do they seem reasonable to you?
And the kernel is infamous for being picky about the C compilers it can be successfully built with - clang couldn’t build a working kernel for a long time, and it was mostly relying on subtle GCCisms.
Appeal to authority. And an appeal to authority where the authority is blatantly and clearly mistaken. If the code has UB, there is no guarantee from Rust's or rustc's sides that it will only crash.
Saying "appeal to authority" doesn't refute the point made above. Expertise is real. Someone with 25 years of experience with the linux kernel will know a lot more about linux and C than the average HN commenter. Almost certainly more than me.
Its possible that you might be right about whatever point you're trying to make. But if you are, I can't tell that from your comments. I can't even find a clear claim in your comments, let alone any substantive argument in support of that claim.
> And a few days ago a security vulnerability was found in the Rust Linux kernel code.
was it a security vulnerability? I'm pretty sure it was "just" a crash. Though maybe someone smarter than me could have turned that into something more.
I have no dog in this race, I really like the idea of Rust drivers but can very much understand retiscience at getting Rust to be handling more core parts of the kernel, just because Rust's value seems to pay off way more in higher level code where you have these invariants to maintain across large code paths (meanwhile writing a bunch of doubly-linked lists in unsafe Rust seems a bit like busy work, modulo the niceties Rust itself can give you)
> was it a security vulnerability? I'm pretty sure it was "just" a crash.
It's a race condition resulting in memory corruption.[1][2] That corruption is shown to result in a crash. I don't think the implication is that it can result only in crashes, but this is not mentioned in the CVE.
Whether it is a vulnerability that an attacker can crash a system depends on your security model, I guess. In general it is not expected to happen and it stops other software from running, and can be controlled by entities or software who should not have that level of control, so it's considered a vulnerability.
It is entertaining to observe that how - after the bullshit and propaganda phase - Rust now slowly enters reality and the excuses for problems that did not magically disappear are now exactly the same as what we saw before from C programmers and which Rust proponents would have completely dismissed as unacceptable in the past ("this CVE is not exploitable", "all programmers make mistakes", "unwrap should never been used in production", "this really is an example how fantastic Rust is").
> Of course, this bug was in an `unsafe` block, which is exactly what you would expect given Rust's promises.
The fix was outside of any Rust unsafe blocks. Which confused a lot of Rust developers on Reddit and elsewhere. Since fans of Rust have often repeated that only unsafe blocks have to be checked. Despite the Rustonomicon clearly spelling out that much more than the unsafe blocks might need to be checked in order to avoid UB.
There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs." Of course, not everybody made such claims, but some did.
Whether it is "significantly easier" to manage these types of problems and at what cost remains to be seen.
I do not understand you comment about "confirmation bias" as did not make a quantitative prediction that could have bias.
> There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs."
Safe Rust does do this. Dropping into unsafe Rust is the prerogative of the programmer who wants to take on the burden of preventing bugs themselves. Part of the technique of Rust programming is minimising the unsafe part so memory errors are eliminated as much as possible.
If the kernel could be written in 100% safe Rust, then any memory error would be a compiler bug.
Is it any more or less amusimg, or perhaps tedious, watching the first Rust Linux kernel CVE be pounced on as evidence that "problems .. did not magically disappear"?
Does anyone involved in any of this work believe that a CVE in an unsafe block could not happen?
The TLDR is that this race condition happened with unsafe code, which was needed to interact with existing C code. This was not a vulnerability with Rust's model.
That said, you can absolutely use bad coding practices in Rust that can cause issues, even for a regular programmer.
Using unwrap without dealing with all return cases is one example. Of course, there is a right way to dealing with return methods, but it's up to the programmer to follow it
There are lots of vulnerabilities in the C code, too. Should we remove C or do we accept that fact that no language is perfect since they are used by humans and continue to make improvements and use tools that help us along as time goes forward?
The cherry picking for this one Rust vulnerability to the ~150 C vulnerabilities is such a weird take that I can't help but think people have some weird hatred of Rust.
Your post is curious, for the post I quoted basically argued for just that eventuality for all new code. Even as the new language introduces undefined behavior vulnerabilities.
The promises as stated previously, and the goal as stated by that lwn.net post now, are starkly different. And the poster did not even wait until the new language has proven its worth. And then a UB CVE comes by in the code in the new language.
> So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust.
That both you and that lwn.net poster writes these things, is extraordinarily weird and strange.
I do not think it is weird. Every C bug was taken as clear evidence that we need to abandon C and switch to Rust. So the fact that there are also such bugs in Rust is - while obvious - also important to highlight. So it is not weird hatred against Rust, but hatred against bullshit. And considering that most of the code is C, your 150 C vulnerabilities is a meaningless number, so you still continue with this nonsense.
One C bug was not taken as clear evidence that we need to abandon C and switch to Rust. Hundreds of thousands of very similar bugs, over decades, in common code patterns were. I’ve never understood how other C or C++ developers could seriously question whether Rust solves any safety problems at all. Maybe the tradeoffs aren’t worth it for a particular use case, but how could you find it unimaginable that even just enforced bounds checks would catch lots of bugs that (normal, non-verified) C would miss? Do you doubt that Python code corrupts memory a lot less because you saw a CPython CVE once?
What language do you think Graydon Hoare was spending most of this time writing while he started working of Rust as a side project? Hint: it sure wasn’t Java. Rust is not the product of some developer who has only used 2 scripting languages and had to read the definition of stack-smashing off of Wikipedia showing those C developers how to live in the future. It’s not old enough for many of the developers working on it to have only ever used Rust. It’s mostly C and C++ developers trying to build a new option for solving their same problems.
Giving the size and age of the C ecosystem, the number of bugs is not really a valid argument. We will see an increasing numbers with Rust as Rust is increasingly used. I also do not question that Rust solves some problems. It just solves them rather badly and at high cost while bringing new problems.
I looked at firefox code a decade ago, it was a complete complex nightmare mix of different languages. I can see that this motivated starting something new, but it was not a clean C code base (and not even C).
What number of CVEs is Rust kernel code allowed to have before we have good evidence it’s a categorical failure? Do you turn off KASLR for your Linux machines because there exist CVEs it doesn’t protect against?
The number of memory related bugs is absolutely a valid issue with C when the same bugs are impossible in Rust. The C memory model is a disaster when every computer is connected to the Internet.
> It’s mostly C and C++ developers trying to build a new option for solving their same problems.
I've observed that a lot of the folks I used to meet at ruby conferences have moved to Rust. No idea what led to this, but maybe it's just folks that were generally curious about new programming languages that moved to ruby when it became better known and that the same interest led to adopting Rust.
I worked on a Ruby codebase that moved to Rust - I think that part is mostly cargo-culting cool things in the news to be perfectly honest. There’s type safety advantages, but if Ruby’s performance envelope was even conceivably acceptable for your use-case there are likely better options. I strongly suspect a lot of the friction between Rust and only-C/C++ developers is the product of a bunch of people coming at Rust from higher level languages parroting lines about safety, and then looking at you blankly if you ask how it handles nested pointer indirection.
But I don’t think that applies to the people actually driving the language forward, just those talking a big game on HN/Reddit.
> Every C bug was taken as clear evidence that we need to abandon C and switch to Rust.
I think more charitably it's every "simple" C bug that tends to provoke that reaction. Buffer overflows, use-after-frees, things for which mechanically-enforceable solutions have existed and been widespread for a while. I think more exotic bugs tend to produce more interesting discussions since the techniques for avoiding those bugs tend to be similarly exotic.
> So the fact that there are also such bugs in Rust
Similarly, I think you need to be careful about what exactly "such bugs" encompasses. This bug wasn't one of the above "simple" bugs IMHO, so I would guess an equivalent bug in C code would at least avoid the worst of the more strident calls you so dislike. Hard to say for sure, though, given our unfortunate lack of a time machine.
Okay, fair that since the majority of the codebase is C and that 150 vulnerabilities is probably negligible in comparison since we're talking about ratios, but if we're to be THAT nuanced then we also need to consider that code has been iterated upon for decades, so, I think the point is moot.
The claim has never, ever, been that Rust is bug free. The objective was to help reduce bugs, which is an outcome I've seen first hand in projects I work on. You still seem to speak in aggro terms, so it still feels like an emotional response to Rust.
Safe Rust eliminates some of the more common memory bugs in C. The bug under discussion was written in unsafe Rust—but even that doesn't obviate the huge advantages Rust has over C. Even unsafe Rust, for instance, has far fewer UB gotchas than C. And with Rust, you can isolate the tricky bits in 'unsafe' blocks and write higher-level logic in safe Rust, giving your code an extra layer of protection. C is 100% unsafe—"unsafe at any speed" as I like to say.
IMHO, "C is 100% unsafe" is a misleading way to look at it and the kind of exaggeration which I criticize. Also in C only specific language features are unsafe and not all code, and you can screen for these features and also isolate critical code in helper functions. Saying these features could appear everywhere is no difference from "unsafe" possibly appearing everywhere in Rust. I agree that "unsafe" is easier to find as a keyword, but I do not think this is a fundamental advantage, especially in projects where you have a lot of such "unsafe" blocks.
> in C only specific language features are unsafe and not all code
Using rust's definition of unsafe which is roughly "can cause undefined behaviour" then it seems to me isolating use of these features isn't possible. What is C without:
* Dereferencing pointers
* Array access
* Incrementing signed integers
You can do all of the above without invoking UB, but you can't separate the features in C that can cause UB from the ones that can't.
The first misunderstanding is that safety is a property of the language or not. Rust marketing convinced many people that this is so, but C can be safe or unsafe. Fil-C shows that even all of C can be memory safe (but at a substantial cost in performance). But even just with GCC and Clang, array access and signed integer can be made safe with a compiler flag, and a violation then traps and this is similar to a Rust panic. The cases which can not be dealt with easily are pointer arithmetic, unions, and free and concurrently related issues. And it is very well possible to isolate and review all of these. This will not find all bugs, but neither does this work perfectly for Rust "unsafe" as this bug (and many others) nicely illustrates.
> Saying these features could appear everywhere is no difference from "unsafe" possibly appearing everywhere in Rust.
That's not true in practice: Unsafe code is clearly delineated and can be 100% correctly identified. In C, usage of dangerous features can occur at any point and is much harder to clearly separate.
First, if "unsafe" worked so well 100% time, why did we have this bug? (and many other) So this already obviously wrong statement.
Then yes, you can use dangerous features in C at any time, but obviously you can also use "unsafe" at any time. The only difference is that "unsafe" is clearer to recognize. But how much this is worth is unclear. First, if you do not invalidly reduce the discussion to only memory safety, you need to review all other code anyway! But even then, it is also not true that only the code marked with "unsafe" is relevant. This is major myth. The "unsafe" code can cause UB outside "unsafe" and logic bugs outside "unsafe" can cause bugs unsafe. This does not perfectly decouple if you Rust repeat this nonsense over and over again.
Don't get me wrong, I think the unsafe keyword is good idea. But the magical powers Rust fans attribute to it and the "SAFETY" comment they put next to it tells me they are a bit delusional.
> logic bugs outside "unsafe" can cause bugs unsafe.
This is the wrong understanding of Rust's unsafety encapsulation. For example, no logic bug outside of `unsafe` can cause undefined behavior of Rust std's `Vec` abstraction, which is using underlying unsafe to build.
The point that "because unsafe is used so the entire Rust program is also unsafe" is a real major myth. It's as absurd as saying "because Java runtime using unsafe underlying to build so Java is also unsafe".
The point is that when you start using rust in the real world to get real work done a lot of the promises that were made about safety have to be dropped because you need to boot your computer before the heat death of the universe. The result will be that we end up with something about as safe as C is currently - because CPUs are fundamentally unsafe and we need them to work somehow.
Rust is from the universe in which micro kernels weren't a dead end and we could avoid all the drivers being written in C.
> when you start using rust in the real world to get real work done a lot of the promises that were made about safety have to be dropped because you need to boot your computer before the heat death of the universe.
Safe rust isn't slow like Python, Go or Fil-C. It gets compiled to normal native code just like C and C++. It generally runs just as fast as C. At least, almost all the time. Arrays have runtime bounds checks. And ... thats about it.
> The result will be that we end up with something about as safe as C is currently - because CPUs are fundamentally unsafe and we need them to work somehow.
Nah. Most rust is safe rust. Even in the kernel, not much code actually interacts directly with raw hardware. The argument in favour of moving to rust isn't that it will remove 100% of memory safety bugs. Just that it'll hopefully remove most of them.
Once again, congrats to the R4L team! It's a big milestone and I'm looking forwards to future developments!.
There was a lot of interesting discussion on the previous post [0], but one thing I didn't see was much discussion about this bit:
> The DRM (graphics) subsystem has been an early adopter of the Rust language. It was still perhaps surprising, though, when Airlie (the DRM maintainer) said that the subsystem is only "about a year away" from disallowing new drivers written in C and requiring the use of Rust.
I was a bit surprised when I first read this. Is this meant to be read in a way that is more just a description of the state of Rust bindings (e.g., the DRM subsystem is about a year away from being able to require the use of Rust, but isn't actually planning on doing so), or it is describing actual plans (e.g., the DRM subsystem is about a year away from actually requiring the use of Rust)? I was originally more inclined to go for the former interpretation, but this other bit:
> With regard to adding core-kernel dependencies on Rust code, Airlie said that it shouldn't happen for another year or two.
Makes me think that perhaps the devs are actually considering the latter. Is anyone more in-the-know able to comment on this?
I'm not more "in the know" but it makes sense that new drivers could require it. New drivers, after all, are pretty much always written for newer platforms that Rust has support for. The main issue with enabling Rust (let alone requiring it) is that Linux still supports platforms which Rust does not.
I don't know. My line of thinking is that if the Linux devs are comfortable with using Rust in core Linux then they might also be comfortable requiring Rust for new drivers as well. No idea if that makes sense, though.
If you build a house out of inflammable bricks instead of magnesium ones you can at least rule out magnesium fires.
Now the question is: If we live in a world where magnesium fires are common, can we afford to not at least try building with the inflammable bricks?
I know this topic stokes emotions, but if you haven't tried Rust as someone with C/C++ experience, give it a go. You will come out wiser on the other side, even if you never use the language for anything.
I've tried it. It's the biggest productivity killer ever. Rust introduces a high amount of complexity at every stage. I need at least 3x the amount of time to write code and read/understand other peoples code.
I can see why mainly big corporations like Microsoft are pushing this onto community projects: Sabotage. It's highly opinionated and divides/disrupts the community and thus minimizes non-corporate community influence. The net benefits are negative by a huge amount on all fronts.
If you really want to help the world to get "safer" you would invest in better static analysis tools and proper annotation of existing C-Code. But it obviously was never about that.
I found it highly complex, but chalked it up to my own unfamiliarity with both C and the rust language and what they are trying to accomplish.
I found C way more approachable and rust filled to the brim with more rabbit holes and "logical-in-their-own-world/reality" way.. but again, I believe that's due to my own inexperience. Truthfully, in 10 years when rust fervor has died down and it has become more normal, I could see people vomitting at the thought that rust was pushed into the kernel, and there to be a strong push for not removing it but rather simplifying the code somehow? I'll definitely be writing another handful of projects in rust again in the next couple of years though, I liked how my last ones ended up
I've done a bit of work with Rust, and while I did find some of the complexity frustrating, it wasn't _that_ bad.
While I could sort of see some situation like you describe with a secret agenda from big tech, I think that probably requires significantly more cunning & organisation than they actually have around this stuff. It's not like Microsoft invented Rust - in fact it came from a relatively small corp in the first place.
It is irrelevant who invented Rust. The relevant fact is that it can be used as a tool to divide the community because of its very opinionated design. Systemd was equally opinionated and also caused huge division. Who is paying the bills of Poettering these days: Microsoft.
The Halloween documents show that Microsoft is playing these games for a long time now. Who knows in which way they have advanced their psyops. Just because we can't read their E-mails anymore doesn't mean they stopped doing it.
>It is irrelevant who invented Rust. The relevant fact is that it can be used as a tool to divide the community because of its very opinionated design.
Compared to C where it has the opinion of no fixed data types making you deal with it.
>Systemd was equally opinionated and also caused huge division. Who is paying the bills of Poettering these days: Microsoft.
Systemd was only opinionated in how it should break posix, because it's meant to be Linux only.
And you're then saying that there is credible evidence that Poettering was a Microsoft mole almost 15 years ago with instructions to create systemd to "disrupt" the Linux ecosystem?
Boy did Microsoft fail there, more distros than ever adopted it and it's these days almost entirely pain free.
>The Halloween documents show that Microsoft is playing these games for a long time now. Who knows in which way they have advanced their psyops. Just because we can't read their E-mails anymore doesn't mean they stopped doing it.
If you have actually read the docs you would know that their strategy is not to divide and conquer as they say FUD does not work, but to instead compete with OSS.
Offtopic but this title makes me want to create an alternate-universe version of the HN front page where every title is shrill/spectacular/hysterical/urgent/clickbaity. Such as:
The Absolute State of the Kernel Rust Experiment Right Now
And every comment has its confidence/aggressiveness taken up to 11 (tho still within site rules).
>Bergmann agreed with declaring the experiment over, worrying only that Rust still "doesn't work on architectures that nobody uses".
I love you Arnd. More seriously, this will become an issue when someone starts the process of integrating Rust code into a core subsystem. I wonder whether this will lead to the kernel dropping support for some architectures, or to Rust doing the necessary work. Probably a bit of both.
There are two separate ongoing projects to make a rust compiler that uses GCC as a backend (one on the gcc side adding a c++ frontend that directly reads rust, one on the rustc side to make rustc emit an intermediate format that gcc can ingest).
The long-term solution is for either of those to mature to the point where there is rust support everywhere that gcc supports.
I wonder how good a LLVM backend for these rare architectures would have to be for that to be “good enough” for the kernel team. Obviously correctness should be non-negotiable, but how important is it that the generated e.g. Alpha code is performant for somebody’s hobby?
I suspect more the latter than anything. It could be that by the time Rust gets used in the kernel core, one or both of the GCC implementations would be functional enough to compile the kernel.
I'm curious though, if someone has an ancient/niche architecture, what's the benefit of wanting newer kernels to the point where it'd be a concern for development?
I presume that outside of devices and drivers, there's little to no new developments in those architectures. In which case, why don't the users/maintainers of those archs use a pre-6.1 kernel (IIRC when Rust was introduced) and backport what they need?
No one is doing any kind of serious computing on 30 year old CPUs. But the point of the hobby isn’t turning on the computer and doing nothing with it. The hobby is putting together all the pieces you need to turn it on, turning it on and then doing nothing with it.
There’s an asymmetry in what the retro computing enthusiasts are asking for and the amount of effort they’re willing to put in. This niche hobby benefits from the free labour of open source maintaining support for their old architectures. If the maintainers propose dropping support because of the cost of maintenance the hobbyists rarely step up. Instead they make it seem like the maintainers are the bad guys doing a reprehensible thing.
You propose they get their hands dirty and cherry pick changes from newer kernels. But they don’t want to put in effort like that. And they might just feel happier that they’re using the “real” latest kernel.
The kernel must adapt to Rust, not the other way around. Rust is the way!
From the comment section:
> To me the more salient questions are how long before (a) we get Rust in a core subsystem (thus making Rust truly _required_ instead of "optional unless you have hardware foo"), and (b) requiring Rust for _all_ new code.
Previously, the position was that C developers would not be forced to learn Rust.
And a few days ago a security vulnerability was found in the Rust Linux kernel code.
https://news.ycombinator.com/item?id=46309536
Where did anyone promise that the Rust bits will never have security issues? That CVE was a fantastic demonstration of just how much better the situation is in Rust code and I don't think there's a realistic argument that the experiment has been anything other than successful.
Was it? It seems more a fantastic demonstration how the same type of errors can also occur in Rust code.
In C this kind of issue is so common it wouldn't raise to the status of "CVE". People would just shrug and say "git gud".
This is certainly not true. But also arguments about "common" are completely misleading as long as there is many orders of magnitude more C code than Rust code.
Maybe you haven't been paying much attention in this space. Google found empirically that error density in _unsafe_ Rust is still much lower than in C/C++. And only a small portion of code is unsafe. So per LOC Rust has orders of magnitudes fewer errors than C/C++ in real world Android development. And these are not small sample sizes. By now more code is being written in Rust than C++ at Google:
https://security.googleblog.com/2025/11/rust-in-android-move...
But don't take my word for it, you can hear about the benefits of Rust directly from GKH:
www.youtube.com/watch?v=HX0GH-YJbGw
There really isn't a good faith argument here. You can make mistakes in Rust? No one denies that. There is more C code so of course there are more mistakes in C code than in Rust? Complete red herring.
That isn't "Google", that is a biased Android subteam who want to push Rust and use the apparently atrocious Android C code as an unfair example.
Why don't they use qmail as an example?
> Why don't they use qmail as an example?
Perhaps because qmail is an anomaly, not Android? To remain relatively bug-free, a sizeable C project seems to require a small team and iron discipline. Unix MTAs are actually pretty good examples. With qmail, for a long time, it was just DJB. Postfix has also fared well, and (AFAIK) has a very small team. Both have been architected to religiously check error conditions and avoid the standard library for structure manipulation.
Android is probably more representative of large C (or C++) projects one may encounter in the wild.
What does bias have to do with empirical evidence? Disprove that than driveling about non-tech stuff.
If you are not intellectually capable of following an argument about selective samples (there are C code bases with virtually no bugs), perhaps you should refrain from commenting.
But you know that the mob voting will back you up.
So you can't, and if a "dumbass" like me can understand the importance of empirical evidence but you can't, maybe read up on rational thinking instead of lashing out emotionally.
And this is what happens if a company like MSFT pushes a language to disrupt open source.
The bug of that CVE has undefined behavior, so anything can in principle happen. You and Greg are sorely mistaken. And my post got downvoted.
That is is undefined behavior does not mean it is exploitable. But I also have not seen an argument why a data race should not be exploitable in this context.
I am very wary of going that route. If there is undefined behavior, the compiler is in principle allowed to do anything and everything, unless it promises something beyond what the language promises.
One could then argue that a specific version of a specific compiler with specific settings in a specific case, after investigation of the generated assembly or inspection of what guarantees the compiler provides beyond the language, is not exploitable. But other settings of the compiler and other versions of the compiler and other compilers may have different guarantees and generation of assembly.
The Linux kernel uses, as I understand it, a flag for GCC for C code that disables strict aliasing. That basically means that strict aliasing is no longer undefined behavior, as long as that flag is used. Basically a dialect of C.
It is very common for C implementation to define undefined behavior and also common for C programs to rely on this. For this reason, I think it is very misleading to say that undefined behavior is automatically exploitable or even a bug.
I think defining terminology here might help.
An attempt:
Language-UB (L-UB): UB according to the guarantees of the language.
Project-compiler-UB (PC-UB): The project picks compilers and compiler settings to create a stronger set of guarantees, that turns some language-UB into not being UB. Examples include turning off the strict aliasing requirement in the used compilers, or a compiler by default defining some language-UB as being defined behavior.
I do not know if such terms might catch on, though. Do they seem reasonable to you?
And the kernel is infamous for being picky about the C compilers it can be successfully built with - clang couldn’t build a working kernel for a long time, and it was mostly relying on subtle GCCisms.
> You and Greg are sorely mistaken.
Greg Kroah-Hartman has been a Linux kernel developer for 25 years, responsible for large parts of the kernel.
You’ve been a hacker news commenter for 1 day.
Could you pipe down with these wild claims that you know better than him?
Also, please don’t complain about downvotes. It’s tedious to read.
Appeal to authority. And an appeal to authority where the authority is blatantly and clearly mistaken. If the code has UB, there is no guarantee from Rust's or rustc's sides that it will only crash.
This is a valid appeal to genuine expertise not authority.
Saying "appeal to authority" doesn't refute the point made above. Expertise is real. Someone with 25 years of experience with the linux kernel will know a lot more about linux and C than the average HN commenter. Almost certainly more than me.
Its possible that you might be right about whatever point you're trying to make. But if you are, I can't tell that from your comments. I can't even find a clear claim in your comments, let alone any substantive argument in support of that claim.
I'm unmoved and unimpressed.
> And a few days ago a security vulnerability was found in the Rust Linux kernel code.
was it a security vulnerability? I'm pretty sure it was "just" a crash. Though maybe someone smarter than me could have turned that into something more.
I have no dog in this race, I really like the idea of Rust drivers but can very much understand retiscience at getting Rust to be handling more core parts of the kernel, just because Rust's value seems to pay off way more in higher level code where you have these invariants to maintain across large code paths (meanwhile writing a bunch of doubly-linked lists in unsafe Rust seems a bit like busy work, modulo the niceties Rust itself can give you)
> was it a security vulnerability? I'm pretty sure it was "just" a crash.
It's a race condition resulting in memory corruption.[1][2] That corruption is shown to result in a crash. I don't think the implication is that it can result only in crashes, but this is not mentioned in the CVE.
Whether it is a vulnerability that an attacker can crash a system depends on your security model, I guess. In general it is not expected to happen and it stops other software from running, and can be controlled by entities or software who should not have that level of control, so it's considered a vulnerability.
[1] https://www.cve.org/CVERecord/?id=CVE-2025-68260 [2] https://lore.kernel.org/linux-cve-announce/2025121614-CVE-20...
It is entertaining to observe that how - after the bullshit and propaganda phase - Rust now slowly enters reality and the excuses for problems that did not magically disappear are now exactly the same as what we saw before from C programmers and which Rust proponents would have completely dismissed as unacceptable in the past ("this CVE is not exploitable", "all programmers make mistakes", "unwrap should never been used in production", "this really is an example how fantastic Rust is").
You have a wild amount of confirmation bias going on here, though.
Of course, this bug was in an `unsafe` block, which is exactly what you would expect given Rust's promises.
The promise of Rust was never that it is magical. The promise is that it is significantly easier to manage these types of problems.
> Of course, this bug was in an `unsafe` block, which is exactly what you would expect given Rust's promises.
The fix was outside of any Rust unsafe blocks. Which confused a lot of Rust developers on Reddit and elsewhere. Since fans of Rust have often repeated that only unsafe blocks have to be checked. Despite the Rustonomicon clearly spelling out that much more than the unsafe blocks might need to be checked in order to avoid UB.
There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs." Of course, not everybody made such claims, but some did.
Whether it is "significantly easier" to manage these types of problems and at what cost remains to be seen.
I do not understand you comment about "confirmation bias" as did not make a quantitative prediction that could have bias.
> There were certainly a lot of people running around claiming that "Rust eliminates the whole class of memory safety bugs."
Safe Rust does do this. Dropping into unsafe Rust is the prerogative of the programmer who wants to take on the burden of preventing bugs themselves. Part of the technique of Rust programming is minimising the unsafe part so memory errors are eliminated as much as possible.
If the kernel could be written in 100% safe Rust, then any memory error would be a compiler bug.
Safe Rust absolutely eliminates entire categories of bugs
Is it any more or less amusimg, or perhaps tedious, watching the first Rust Linux kernel CVE be pounced on as evidence that "problems .. did not magically disappear"?
Does anyone involved in any of this work believe that a CVE in an unsafe block could not happen?
In case anyone is keen for an explanation of the vulnerability, LowLevelTV has done a video on this:
https://youtu.be/dgPI7NfKCiQ?si=BVBQ0MxuDpsbCvOk
The TLDR is that this race condition happened with unsafe code, which was needed to interact with existing C code. This was not a vulnerability with Rust's model.
That said, you can absolutely use bad coding practices in Rust that can cause issues, even for a regular programmer.
Using unwrap without dealing with all return cases is one example. Of course, there is a right way to dealing with return methods, but it's up to the programmer to follow it
I think you’ve said the quiet part out loud by mentioning learning Rust.
The learning seems to be the only legitimate issue that people have. But they avoid mentioning it because it sounds intellectually lazy.
And it is intellectually lazy.
As Rust's advantages over C continue to be proven, a shift in position to "suck it up, C devs" is to be expected.
There are lots of vulnerabilities in the C code, too. Should we remove C or do we accept that fact that no language is perfect since they are used by humans and continue to make improvements and use tools that help us along as time goes forward?
The cherry picking for this one Rust vulnerability to the ~150 C vulnerabilities is such a weird take that I can't help but think people have some weird hatred of Rust.
> Should we remove C or
Your post is curious, for the post I quoted basically argued for just that eventuality for all new code. Even as the new language introduces undefined behavior vulnerabilities.
The promises as stated previously, and the goal as stated by that lwn.net post now, are starkly different. And the poster did not even wait until the new language has proven its worth. And then a UB CVE comes by in the code in the new language.
What Linus wrote in the past:
https://www.phoronix.com/news/Torvalds-On-Rust-Maintainers
> So when you change the C interfaces, the Rust people will have to deal with the fallout, and will have to fix the Rust bindings. That's kind of the promise here: there's that "wall of protection" around C developers that don't want to deal with Rust issues in the promise that they don't have to deal with Rust.
That both you and that lwn.net poster writes these things, is extraordinarily weird and strange.
But this sounds like hubris and user error, then, and not a language discussion at all?
I do not think it is weird. Every C bug was taken as clear evidence that we need to abandon C and switch to Rust. So the fact that there are also such bugs in Rust is - while obvious - also important to highlight. So it is not weird hatred against Rust, but hatred against bullshit. And considering that most of the code is C, your 150 C vulnerabilities is a meaningless number, so you still continue with this nonsense.
One C bug was not taken as clear evidence that we need to abandon C and switch to Rust. Hundreds of thousands of very similar bugs, over decades, in common code patterns were. I’ve never understood how other C or C++ developers could seriously question whether Rust solves any safety problems at all. Maybe the tradeoffs aren’t worth it for a particular use case, but how could you find it unimaginable that even just enforced bounds checks would catch lots of bugs that (normal, non-verified) C would miss? Do you doubt that Python code corrupts memory a lot less because you saw a CPython CVE once?
What language do you think Graydon Hoare was spending most of this time writing while he started working of Rust as a side project? Hint: it sure wasn’t Java. Rust is not the product of some developer who has only used 2 scripting languages and had to read the definition of stack-smashing off of Wikipedia showing those C developers how to live in the future. It’s not old enough for many of the developers working on it to have only ever used Rust. It’s mostly C and C++ developers trying to build a new option for solving their same problems.
Giving the size and age of the C ecosystem, the number of bugs is not really a valid argument. We will see an increasing numbers with Rust as Rust is increasingly used. I also do not question that Rust solves some problems. It just solves them rather badly and at high cost while bringing new problems.
I looked at firefox code a decade ago, it was a complete complex nightmare mix of different languages. I can see that this motivated starting something new, but it was not a clean C code base (and not even C).
What number of CVEs is Rust kernel code allowed to have before we have good evidence it’s a categorical failure? Do you turn off KASLR for your Linux machines because there exist CVEs it doesn’t protect against?
The number of memory related bugs is absolutely a valid issue with C when the same bugs are impossible in Rust. The C memory model is a disaster when every computer is connected to the Internet.
> It’s mostly C and C++ developers trying to build a new option for solving their same problems.
I've observed that a lot of the folks I used to meet at ruby conferences have moved to Rust. No idea what led to this, but maybe it's just folks that were generally curious about new programming languages that moved to ruby when it became better known and that the same interest led to adopting Rust.
I worked on a Ruby codebase that moved to Rust - I think that part is mostly cargo-culting cool things in the news to be perfectly honest. There’s type safety advantages, but if Ruby’s performance envelope was even conceivably acceptable for your use-case there are likely better options. I strongly suspect a lot of the friction between Rust and only-C/C++ developers is the product of a bunch of people coming at Rust from higher level languages parroting lines about safety, and then looking at you blankly if you ask how it handles nested pointer indirection.
But I don’t think that applies to the people actually driving the language forward, just those talking a big game on HN/Reddit.
> Every C bug was taken as clear evidence that we need to abandon C and switch to Rust.
I think more charitably it's every "simple" C bug that tends to provoke that reaction. Buffer overflows, use-after-frees, things for which mechanically-enforceable solutions have existed and been widespread for a while. I think more exotic bugs tend to produce more interesting discussions since the techniques for avoiding those bugs tend to be similarly exotic.
> So the fact that there are also such bugs in Rust
Similarly, I think you need to be careful about what exactly "such bugs" encompasses. This bug wasn't one of the above "simple" bugs IMHO, so I would guess an equivalent bug in C code would at least avoid the worst of the more strident calls you so dislike. Hard to say for sure, though, given our unfortunate lack of a time machine.
I agree with you that this is more nuanced and that I oversimplified this a bit in my comment.
Okay, fair that since the majority of the codebase is C and that 150 vulnerabilities is probably negligible in comparison since we're talking about ratios, but if we're to be THAT nuanced then we also need to consider that code has been iterated upon for decades, so, I think the point is moot.
The claim has never, ever, been that Rust is bug free. The objective was to help reduce bugs, which is an outcome I've seen first hand in projects I work on. You still seem to speak in aggro terms, so it still feels like an emotional response to Rust.
A million memory error bugs is used as a valid argument to stop using C and switch to rust where such bugs are impossible.
Safe Rust eliminates some of the more common memory bugs in C. The bug under discussion was written in unsafe Rust—but even that doesn't obviate the huge advantages Rust has over C. Even unsafe Rust, for instance, has far fewer UB gotchas than C. And with Rust, you can isolate the tricky bits in 'unsafe' blocks and write higher-level logic in safe Rust, giving your code an extra layer of protection. C is 100% unsafe—"unsafe at any speed" as I like to say.
IMHO, "C is 100% unsafe" is a misleading way to look at it and the kind of exaggeration which I criticize. Also in C only specific language features are unsafe and not all code, and you can screen for these features and also isolate critical code in helper functions. Saying these features could appear everywhere is no difference from "unsafe" possibly appearing everywhere in Rust. I agree that "unsafe" is easier to find as a keyword, but I do not think this is a fundamental advantage, especially in projects where you have a lot of such "unsafe" blocks.
> in C only specific language features are unsafe and not all code
Using rust's definition of unsafe which is roughly "can cause undefined behaviour" then it seems to me isolating use of these features isn't possible. What is C without:
* Dereferencing pointers * Array access * Incrementing signed integers
You can do all of the above without invoking UB, but you can't separate the features in C that can cause UB from the ones that can't.
The first misunderstanding is that safety is a property of the language or not. Rust marketing convinced many people that this is so, but C can be safe or unsafe. Fil-C shows that even all of C can be memory safe (but at a substantial cost in performance). But even just with GCC and Clang, array access and signed integer can be made safe with a compiler flag, and a violation then traps and this is similar to a Rust panic. The cases which can not be dealt with easily are pointer arithmetic, unions, and free and concurrently related issues. And it is very well possible to isolate and review all of these. This will not find all bugs, but neither does this work perfectly for Rust "unsafe" as this bug (and many others) nicely illustrates.
> Saying these features could appear everywhere is no difference from "unsafe" possibly appearing everywhere in Rust.
That's not true in practice: Unsafe code is clearly delineated and can be 100% correctly identified. In C, usage of dangerous features can occur at any point and is much harder to clearly separate.
First, if "unsafe" worked so well 100% time, why did we have this bug? (and many other) So this already obviously wrong statement.
Then yes, you can use dangerous features in C at any time, but obviously you can also use "unsafe" at any time. The only difference is that "unsafe" is clearer to recognize. But how much this is worth is unclear. First, if you do not invalidly reduce the discussion to only memory safety, you need to review all other code anyway! But even then, it is also not true that only the code marked with "unsafe" is relevant. This is major myth. The "unsafe" code can cause UB outside "unsafe" and logic bugs outside "unsafe" can cause bugs unsafe. This does not perfectly decouple if you Rust repeat this nonsense over and over again.
Don't get me wrong, I think the unsafe keyword is good idea. But the magical powers Rust fans attribute to it and the "SAFETY" comment they put next to it tells me they are a bit delusional.
> logic bugs outside "unsafe" can cause bugs unsafe.
This is the wrong understanding of Rust's unsafety encapsulation. For example, no logic bug outside of `unsafe` can cause undefined behavior of Rust std's `Vec` abstraction, which is using underlying unsafe to build.
The point that "because unsafe is used so the entire Rust program is also unsafe" is a real major myth. It's as absurd as saying "because Java runtime using unsafe underlying to build so Java is also unsafe".
The safest computer is a rock.
The point is that when you start using rust in the real world to get real work done a lot of the promises that were made about safety have to be dropped because you need to boot your computer before the heat death of the universe. The result will be that we end up with something about as safe as C is currently - because CPUs are fundamentally unsafe and we need them to work somehow.
Rust is from the universe in which micro kernels weren't a dead end and we could avoid all the drivers being written in C.
> when you start using rust in the real world to get real work done a lot of the promises that were made about safety have to be dropped because you need to boot your computer before the heat death of the universe.
Safe rust isn't slow like Python, Go or Fil-C. It gets compiled to normal native code just like C and C++. It generally runs just as fast as C. At least, almost all the time. Arrays have runtime bounds checks. And ... thats about it.
> The result will be that we end up with something about as safe as C is currently - because CPUs are fundamentally unsafe and we need them to work somehow.
Nah. Most rust is safe rust. Even in the kernel, not much code actually interacts directly with raw hardware. The argument in favour of moving to rust isn't that it will remove 100% of memory safety bugs. Just that it'll hopefully remove most of them.
Once again, congrats to the R4L team! It's a big milestone and I'm looking forwards to future developments!.
There was a lot of interesting discussion on the previous post [0], but one thing I didn't see was much discussion about this bit:
> The DRM (graphics) subsystem has been an early adopter of the Rust language. It was still perhaps surprising, though, when Airlie (the DRM maintainer) said that the subsystem is only "about a year away" from disallowing new drivers written in C and requiring the use of Rust.
I was a bit surprised when I first read this. Is this meant to be read in a way that is more just a description of the state of Rust bindings (e.g., the DRM subsystem is about a year away from being able to require the use of Rust, but isn't actually planning on doing so), or it is describing actual plans (e.g., the DRM subsystem is about a year away from actually requiring the use of Rust)? I was originally more inclined to go for the former interpretation, but this other bit:
> With regard to adding core-kernel dependencies on Rust code, Airlie said that it shouldn't happen for another year or two.
Makes me think that perhaps the devs are actually considering the latter. Is anyone more in-the-know able to comment on this?
[0]: https://news.ycombinator.com/item?id=46213585
I'm not more "in the know" but it makes sense that new drivers could require it. New drivers, after all, are pretty much always written for newer platforms that Rust has support for. The main issue with enabling Rust (let alone requiring it) is that Linux still supports platforms which Rust does not.
Is DRM considered core kernel dependencies?
I don't know. My line of thinking is that if the Linux devs are comfortable with using Rust in core Linux then they might also be comfortable requiring Rust for new drivers as well. No idea if that makes sense, though.
Somewhat related, a kernel in Rust: https://github.com/jgarzik/hk
If you're going to plug your own project, you might want to mention that in your comment.
There's dozens of rust osdev projects. Its an open question if any become relevant like linux.
If you build a house out of inflammable bricks instead of magnesium ones you can at least rule out magnesium fires.
Now the question is: If we live in a world where magnesium fires are common, can we afford to not at least try building with the inflammable bricks?
I know this topic stokes emotions, but if you haven't tried Rust as someone with C/C++ experience, give it a go. You will come out wiser on the other side, even if you never use the language for anything.
I've tried it. It's the biggest productivity killer ever. Rust introduces a high amount of complexity at every stage. I need at least 3x the amount of time to write code and read/understand other peoples code.
I can see why mainly big corporations like Microsoft are pushing this onto community projects: Sabotage. It's highly opinionated and divides/disrupts the community and thus minimizes non-corporate community influence. The net benefits are negative by a huge amount on all fronts.
If you really want to help the world to get "safer" you would invest in better static analysis tools and proper annotation of existing C-Code. But it obviously was never about that.
I found it highly complex, but chalked it up to my own unfamiliarity with both C and the rust language and what they are trying to accomplish.
I found C way more approachable and rust filled to the brim with more rabbit holes and "logical-in-their-own-world/reality" way.. but again, I believe that's due to my own inexperience. Truthfully, in 10 years when rust fervor has died down and it has become more normal, I could see people vomitting at the thought that rust was pushed into the kernel, and there to be a strong push for not removing it but rather simplifying the code somehow? I'll definitely be writing another handful of projects in rust again in the next couple of years though, I liked how my last ones ended up
I've done a bit of work with Rust, and while I did find some of the complexity frustrating, it wasn't _that_ bad.
While I could sort of see some situation like you describe with a secret agenda from big tech, I think that probably requires significantly more cunning & organisation than they actually have around this stuff. It's not like Microsoft invented Rust - in fact it came from a relatively small corp in the first place.
It is irrelevant who invented Rust. The relevant fact is that it can be used as a tool to divide the community because of its very opinionated design. Systemd was equally opinionated and also caused huge division. Who is paying the bills of Poettering these days: Microsoft.
The Halloween documents show that Microsoft is playing these games for a long time now. Who knows in which way they have advanced their psyops. Just because we can't read their E-mails anymore doesn't mean they stopped doing it.
>It is irrelevant who invented Rust. The relevant fact is that it can be used as a tool to divide the community because of its very opinionated design.
Compared to C where it has the opinion of no fixed data types making you deal with it.
>Systemd was equally opinionated and also caused huge division. Who is paying the bills of Poettering these days: Microsoft.
Systemd was only opinionated in how it should break posix, because it's meant to be Linux only.
And you're then saying that there is credible evidence that Poettering was a Microsoft mole almost 15 years ago with instructions to create systemd to "disrupt" the Linux ecosystem?
Boy did Microsoft fail there, more distros than ever adopted it and it's these days almost entirely pain free.
>The Halloween documents show that Microsoft is playing these games for a long time now. Who knows in which way they have advanced their psyops. Just because we can't read their E-mails anymore doesn't mean they stopped doing it.
If you have actually read the docs you would know that their strategy is not to divide and conquer as they say FUD does not work, but to instead compete with OSS.
What project has been pushed to rewrite in rust that explicitly Microsoft has been the culprit in?
And not individuals who work at Microsoft does not count.
> And not individuals who work at Microsoft does not count.
How in the world does this not count? People act in the interest of those who pay the bills.
>How in the world does this not count? People act in the interest of those who pay the bills.
Guilty by association?
So do you have evidence of Microsoft the company doing this or not?
https://en.wikipedia.org/wiki/Sealioning
How do you know something was written in Rust? -- they'll tell you.
There goes the neighborhood.
Offtopic but this title makes me want to create an alternate-universe version of the HN front page where every title is shrill/spectacular/hysterical/urgent/clickbaity. Such as:
The Absolute State of the Kernel Rust Experiment Right Now
And every comment has its confidence/aggressiveness taken up to 11 (tho still within site rules).
This author is not someone who should be reporting on Rust especially in the kernel: https://www.youtube.com/watch?v=gVC1gp2PS8U&t=1538s
Mind elaborating on what exactly is wrong in that video? Or how that is relevant to the article's contents?