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

91–100 of 148 posts

Re: The state of the kernel Rust experiment

#91

Post by UltraSane »

uecker wrote: post #52
simonask wrote: post #47

Earlier quoted context omitted.

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.

Safe Rust absolutely eliminates entire categories of bugs

Re: The state of the kernel Rust experiment

#92

Post by abelitoo »

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

Re: The state of the kernel Rust experiment

#94

Post by UltraSane »

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.

A million memory error bugs is used as a valid argument to stop using C and switch to rust where such bugs are impossible.

Re: The state of the kernel Rust experiment

#95

Post by dannersy »

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.

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.

Re: The state of the kernel Rust experiment

#96

Post by UltraSane »

uecker wrote: post #84
johncolanduoni wrote: post #58

Earlier quoted context omitted.

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

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…

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.

Re: The state of the kernel Rust experiment

#97

Post by dannersy »

yourdetect wrote: post #22
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.

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

But this sounds like hubris and user error, then, and not a language discussion at all?

Re: The state of the kernel Rust experiment

#98

Post by uecker »

wmanley wrote: post #73
uecker wrote: post #49

Earlier quoted context omitted.

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

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

Re: The state of the kernel Rust experiment

#99

Post by johncolanduoni »

uecker wrote: post #84
johncolanduoni wrote: post #58

Earlier quoted context omitted.

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

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…

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?

Re: The state of the kernel Rust experiment

#100

Post by Pannoniae »

johncolanduoni wrote: post #88
Pannoniae wrote: post #81

Earlier quoted context omitted.

This comment is interesting and adds to the discussion but it would be quite a bit better without the flamewar-style swipes in the last sentence :)

Please explain how it adds to the discussion about different ways to broaden supported Rust target architectures. Because both have the word Rust in them?

It contained an interesting link and I tried to be friendly. You're right though, not very on topic.
Post reply on HN