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

131–140 of 148 posts

Re: The state of the kernel Rust experiment

#131

Post by ivanbakel »

uecker wrote: post #104
ivanbakel wrote: post #61

Earlier quoted context omitted.

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

Yes, but this is the marketing bullshit I am calling out. "Safe Rust" != "Rust" and it is not "Safe Rust" which is competing with C it is "Rust".

> it is not "Safe Rust" which is competing with C it is "Rust".

It is intended that Safe Rust be the main competitor to C. You are not meant to write your whole program in unsafe Rust using raw pointers - that would indicate a significant failure of Rust’s expressive power.

Its true that many Rust programs involve some element of unsafe Rust, but that unsafety is meant to be contained and abstracted, not pervasive throughout the program. That’s a significant difference from how C’s unsafety works.

Re: The state of the kernel Rust experiment

#132

Post by aw1621107 »

uecker wrote: post #124
wmanley wrote: post #113

Earlier quoted context omitted.

I guess that means you're using the colloquial meaning of the word safety/unsafe rather than the rust definition. It's worth being explicit about that (or choosing a different word) in these discussions to prevent confusion. For Rust safety (meaning no UB) most definitely is a property of the language. If a module does not contain unsafe and the modules it uses that do contain unsafe are implemented soundly then ther…

No, in the comment you reply to, I am using safe/unsafe in the Rust sense. E.g. signed overflow changed to trap avoids the UB. Also "If .. are implemented soundly" sounds harmless but simply means there is no safety guarantee (in contrast to Fil-C or formally verified C, for example). It relies on best-effort manual review. (but even without "unsafe" use anywhere, there are various issues in Rust's type system which…

> Also "If .. are implemented soundly" sounds harmless but simply means there is no safety guarantee (in contrast to Fil-C or formally verified C, for example).

Don't those also depend on implementations being sound? Fil-C has its own unsafe implementation, formal verification tools have their trusted kernels, it's turtles all the way down.

Re: The state of the kernel Rust experiment

#133

Post by qingcharles »

bitwize wrote: post #42
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…

As Rust's advantages over C continue to be proven, a shift in position to "suck it up, C devs" is to be expected.

Agree. As a dev I've had to pivot a dozen times in my career. If you're a dev you should be able to learn a new language fairly quickly, all the core elements are the same, just the vocabulary is a little different. Since nobody has "fixed" C to avoid these bugs, and we're not going to go as far as put Java or .Net in the kernel, then I think Rust is probably the best, most pragmatic solution we have right now.

Re: The state of the kernel Rust experiment

#134

Post by thegrim000 »

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…

Well yeah, that's the strategy.

"You don't need to learn it or use it, we just want to do our own separate things with it over here"

.. some time later ..

"Oh yeah it's working good for us, we think it'd be useful to use it in these additional places, think about the benefits!"

.. some time later ..

"Now it's going to be core and required, either deal with it or get out"

They know they could never jump straight to the last step without revolt, so they shove their foot in the door with fake promises and smiles and then slowly over time force the door all the way open until they eventually get what they wanted from the beginning.

Re: The state of the kernel Rust experiment

#135

Post by airstrike »

immibis wrote: post #115
airstrike wrote: post #33

Earlier quoted context omitted.

It's in a block explicitly marked unsafe lmao As opposed to an implicitly unsafe what 1 million lines of C

What good does that do though? They still have the bug, whether it's marked "unsafe" or not. You could mark every C source file as "unsafe" and that wouldn't magically make C a better language or have fewer bugs. This talking point needs to stop. Rust could be a better language but that would be because it causes fewer bugs, not because the bugs are labeled "unsafe"

In which code base is this bug easier to find, especially preemptively?

Your bias is showing.

Re: The state of the kernel Rust experiment

#136

Post by immibis »

airstrike wrote: post #135
immibis wrote: post #115

Earlier quoted context omitted.

What good does that do though? They still have the bug, whether it's marked "unsafe" or not. You could mark every C source file as "unsafe" and that wouldn't magically make C a better language or have fewer bugs. This talking point needs to stop. Rust could be a better language but that would be because it causes fewer bugs, not because the bugs are labeled "unsafe"

In which code base is this bug easier to find, especially preemptively? Your bias is showing.

Well this particular bug was avoided in the C code but not in the Rust code, so if we're going the evidence-based route...

Re: The state of the kernel Rust experiment

#137

Post by airstrike »

immibis wrote: post #136
airstrike wrote: post #135

Earlier quoted context omitted.

In which code base is this bug easier to find, especially preemptively? Your bias is showing.

Well this particular bug was avoided in the C code but not in the Rust code, so if we're going the evidence-based route...

Sure, let's do it. Go ahead and tally the reverse too.

If you want evidence-based, you can't cherry-pick.

Re: The state of the kernel Rust experiment

#138

Post by uecker »

johncolanduoni wrote: post #129
uecker wrote: post #109

Earlier quoted context omitted.

As long as the kernel will be developed, there will be CVEs - even with Rust. So at what point the number is so high that we should drop Rust and move to formal verification? And even then, there will be CVEs... This whole argument is nonsense. But I also do not agree that memory safety is of much higher importance than other issues. Memory safety is highly critical if you have a monopolistic walled garden spyware ec…

Your priorities do not match that of most kernel developers or most operators of network-connected Linux systems (even if we ignore Android). So I don’t think your problem is with Rust at all, you’ll need to fork Linux if you want the project to stop putting huge amounts of effort into memory safety (as it has for decades).

You are right, I do not have a problem with Rust as a language nor with the kernel improving memory safety. My issue is solely with exaggerated claims and aggressive marketing of Rust.

(And I am operating network-connected Linux devices since 30 years myself. Memory safety is not the known issue, at the moment I worry more about limited security updates due to Rust.)

Re: The state of the kernel Rust experiment

#139

Post by uecker »

aw1621107 wrote: post #132
uecker wrote: post #124

Earlier quoted context omitted.

No, in the comment you reply to, I am using safe/unsafe in the Rust sense. E.g. signed overflow changed to trap avoids the UB. Also "If .. are implemented soundly" sounds harmless but simply means there is no safety guarantee (in contrast to Fil-C or formally verified C, for example). It relies on best-effort manual review. (but even without "unsafe" use anywhere, there are various issues in Rust's type system which…

> Also "If .. are implemented soundly" sounds harmless but simply means there is no safety guarantee (in contrast to Fil-C or formally verified C, for example). Don't those also depend on implementations being sound? Fil-C has its own unsafe implementation, formal verification tools have their trusted kernels, it's turtles all the way down.

The implementation itself being sound, yes. And yes, in Rust if you only use sound libraries (in combination), never use unsafe yourself and ignore the known defects in Rust, then it is also guaranteed to be safe. But in system programming, you usually have to use "unsafe" in your own code, and then there is no guarantee and you make sure the could has no UB yourself, just like in C.

Re: The state of the kernel Rust experiment

#140

Post by Certhas »

uecker wrote: post #103
Certhas wrote: post #55

Earlier quoted context omitted.

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…

Hey, it was my point that the number of CVEs is red herring. And no, I do not care or even believe what Google says. There are so many influencing factors.

The thing is. There always was a strong theoretical case that Rust should improve software quality (not just because of the fact that you have a lifetime system). The only reasonable counterpoint was that this is theory, and large scale experience is missing. Maybe in high quality code bases the mental overhead of using Rust would outweigh the theoretical guarantees, and the type of mistakes prevented are already caught by C/C++ tooling anyways?

The (in recent years) rapid adoption of Rust in industry clearly shows that this is not the case.

Post reply on HN