Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The state of the kernel Rust experiment

lwn.net

Post reply on HN
Print view View original

51–60 of 148 posts

Re: The state of the kernel Rust experiment

#51

Post by [deleted] »

testdelacc1 wrote: post #43
nevi-me wrote: post #36

Earlier quoted context omitted.

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…

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…

[deleted]

Re: The state of the kernel Rust experiment

#52

Post by uecker »

simonask wrote: post #47
uecker wrote: post #21

Earlier quoted context omitted.

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 u…

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.

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.

Re: The state of the kernel Rust experiment

#53

Post by johncolanduoni »

uecker wrote: post #31
yourdetect wrote: post #29

Earlier quoted context omitted.

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 t…

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.

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.

Re: The state of the kernel Rust experiment

#54

Post by dwattttt »

uecker wrote: post #21
taneliv wrote: post #11

Earlier quoted context omitted.

> 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 expe…

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 u…

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?

Re: The state of the kernel Rust experiment

#55

Post by Certhas »

uecker wrote: post #15
jrimbault wrote: post #14

Earlier quoted context omitted.

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.

Re: The state of the kernel Rust experiment

#56

Post by sprash »

atoav wrote: post #41

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,…

[flagged]

Re: The state of the kernel Rust experiment

#57

Post by bgwalter »

Certhas wrote: post #55
uecker wrote: post #15

Earlier quoted context omitted.

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.goo…

[flagged]

Re: The state of the kernel Rust experiment

#58

Post by johncolanduoni »

uecker wrote: post #27
dannersy wrote: post #19

Earlier quoted context omitted.

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.

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.

Re: The state of the kernel Rust experiment

#59

Post by CamouflagedKiwi »

sprash wrote: post #56
atoav wrote: post #41

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,…

[flagged]

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.

Re: The state of the kernel Rust experiment

#60

Post by johncolanduoni »

Tuna-Fish wrote: post #46
Jean-Papoulos wrote: post #26

>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?
Post reply on HN