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

21–30 of 148 posts

Re: The state of the kernel Rust experiment

#21

Post by uecker »

taneliv wrote: post #11
rtpg wrote: post #4

Earlier quoted context omitted.

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

> 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 used in production", "this really is an example how fantastic Rust is").

Re: The state of the kernel Rust experiment

#22

Post by yourdetect »

dannersy wrote: post #19
yourdetect wrote: post #2

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…

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.

Re: The state of the kernel Rust experiment

#23

Post by uecker »

yourdetect wrote: post #18
AlotOfReading wrote: post #3

Earlier quoted context omitted.

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.

[flagged]

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.

Re: The state of the kernel Rust experiment

#24

Post by chironjit »

taneliv wrote: post #11
rtpg wrote: post #4

Earlier quoted context omitted.

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

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

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

Re: The state of the kernel Rust experiment

#26

Post by Jean-Papoulos »

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

Re: The state of the kernel Rust experiment

#27

Post by uecker »

dannersy wrote: post #19
yourdetect wrote: post #2

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…

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.

Re: The state of the kernel Rust experiment

#28

Post by ibotty »

yourdetect wrote: post #25
Rakshath_1 wrote: post #16

[flagged]

[flagged]

There is relatively little Rust in the kernel, but there are even less Rust CVEs. In this cycle alone there were 160 CVEs, one in Rust. The first one! The amount of rust is way less than 1/160 and even that statistic is off, because one should count all CVEs.

Re: The state of the kernel Rust experiment

#29

Post by yourdetect »

uecker wrote: post #23
yourdetect wrote: post #18

Earlier quoted context omitted.

[flagged]

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.

Re: The state of the kernel Rust experiment

#30

Post by aw1621107 »

yourdetect wrote: post #25
Rakshath_1 wrote: post #16

[flagged]

[flagged]

There's this bit from the article which might provide a hint:

> Drivers in Rust, [Greg KH] said, are indeed proving to be far safer than those written in C.

And since CVEs haven't been getting assigned to Rust code until recently, I think he's more well-positioned to opine on the safety of Rust code vs. C code in Linux than those who are only indexing off the singular Rust CVE so far.

Post reply on HN