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

“Rust is safe” is not some kind of absolute guarantee of code safety

lkml.org

Post reply on HN
Print view View original

71–80 of 542 posts

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#71

Post by ChrisSD »

arinlen wrote: post #63
a_humean wrote: post #6

I know next to nothing about kernel programming, but I'm not sure here what Linus' objection to the comment he is responding to here is. The comment seemed to be making reference to rust's safety guarantees about undefined behaviour like use after free. Linus' seems to have a completely different definition of "safey" that conflates allocation failures, indexing out of bounds, and division by zero with memory safety.…

> I know next to nothing about kernel programming, but I'm not sure here what Linus' objection to the comment he is responding to here is. You should read the email thread, as Linhas explains in clear terms. Take for instance Linus's insightful followup post: https://lkml.org/lkml/2022/9/19/1250

What is better: continuing to "limp along" in some unknown corrupted state (aka undefined behaviour) or in a well defined (albeit invalid) state?

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#72

Post by kweingar »

aaaaaaaaaaab wrote: post #60
kweingar wrote: post #47

Classic Linus. From the closing paragraph, I feel like he’s under the impression that Rust-advocating contributors are putting Rust’s interests (e.g. “legitimizing it” by getting it in the kernel) above the kernel itself.

Is he wrong?

Regardless of whether he’s right or wrong, I think that this is somewhat natural and is to be expected.

Like with any emerging technology, early adopters become advocates because they’re convinced of the technology’s superiority. Once they organize into a community and get to know each other personally, then at least some of the motivation shifts: you want to see your friends succeed, you want to be part of a community that is making change, you want your early adoption to be “validated” by mainstream success, etc.

This can cloud technical judgment (not saying this is happening here, but if it were, it wouldn’t be surprising)

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#73

Post by fritolaid »

atoav wrote: post #16
tcfhgj wrote: post #7

> Not completing the operation at all, is not really any better than getting the wrong answer, it's only more debuggable. Wouldn't be that sure about that. Getting the wrong answer can be a serious security problem. Not completing the operation... well, it is not good, but that's it.

I mean if it is a cosmetic thing sure. If it has substantial meaning I would rather have that 5 ton robotic welding arm not move than have it move through my skill. It is sometimes acceptable to get wrong output. But is nearly always better to know it is wrong.

Unless it was holding a welding gun and stopped on one spot with the welding flame turned on instead of gracefully turning off the flame and backing away.

Never used Rust before but is there a way to supply some default code to run in such a situation instead of just not carrying out the bad operation?

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#74

Post by TillE »

PragmaticPulp wrote: post #49

I’ve been using Rust for a while, and I’m so, so tired of hearing this argument. Yes, we know. We get it. Rust is not an absolute guarantee of safety and doesn’t protect us from all the bugs. This is obvious and well-known to anyone actually using Rust. At this point, the argument feels like some sort of ideological debate happening outside the realm of actually getting work done. It feels like any time someone says…

It's really common to see people say meaningless stuff like "Rust is a safe language" which is either deeply confused or deeply misleading.

Rust provides certain guarantees of memory safety, which is great, but it's important to understand exactly what that means and not to oversell it.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#75

Post by wokwokwok »

throwawaybutwhy wrote: post #2

To put things in context, Linus is being reasonable and wise and well-mannered once again. Wouldn't mind reading a few juicy expletives, to be honest.

>>>>> For GFP_ATOMIC, we could use preempt_count except that it isn't always enabled. Conveniently, it is already separated out into its own config. How do people feel about removing CONFIG_PREEMPT_COUNT and having the count always enabled?

>>>> No (Linus)

>>> As you know, we're trying to guarantee the absence of undefined behaviour for code written in Rust. And the context is _really_ important, so important that leaving it up to comments isn't enough.

…

>>> Do you have an opinion on the above?

>> This message. Ie. No. you can’t make everyone play by your rules. (Linus, grumpily)

> While I disagree with some of what you write, the point is taken.

> But I won't give up on Rust guarantees just yet, I'll try to find ergonomic ways to enforce them at compile time.

I mean, it doesn’t sound like he’s being petty or misunderstanding.

They want special rules (which won’t work) to do runtime checking for rust code. That seems weird, right?

Rust safety should be compile time. That’s the point…

I dunno, maybe I don’t understand what’s being said, but I don’t think Linus is particularly wrong here, even if it’s kind of shouty.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#77

Post by a_humean »

Vt71fcAqt7 wrote: post #57
a_humean wrote: post #31

Earlier quoted context omitted.

Which is why Rust has been accommodating the kernel by adding non-panic versions of the functions that Linus has been complaining about (namely that memory allocation is infallible, because that isn't an unreasonable thing to assume in applicationc code.). Still doesn't change the fact that "safe" in this context has a technical meaning, and what Linus is describing isn't that.

maybe his point is that the technical meaning should use a more acurate word in his opinion?

His point seems to be the opposite, that "safety" should have a vaguer meaning in his opinion, and not the well established technical definition that the author clearly meant when he used the word.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#78

Post by chrsig »

PragmaticPulp wrote: post #49

I’ve been using Rust for a while, and I’m so, so tired of hearing this argument. Yes, we know. We get it. Rust is not an absolute guarantee of safety and doesn’t protect us from all the bugs. This is obvious and well-known to anyone actually using Rust. At this point, the argument feels like some sort of ideological debate happening outside the realm of actually getting work done. It feels like any time someone says…

I mean, it's felt like anytime anyone mentions any code base not written in rust, someone pops in and points out that it's not safe, and should be rewritten in rust.

I think it's all part of the language maturing process. Give it time, zealots will either move on to something new (and then harass the rust community for not meeting their new standard of excellence) or simmer down and get to work.

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#79

Post by blinkingled »

> Even "safe" rust code in user space will do things like panic when things go wrong (overflows, allocation failures, etc). If you don't realize that that is NOT some kind of true safely[sic], I don't know what to say.

> Not completing the operation at all, is not really any better than getting the wrong answer, it's only more debuggable.

What Linus is saying is 100% right of course - he is trying to set the expectations straight in saying that just because you replaced C code with multi thousands (or whatever huge number) of man months of efforts, corrections and refinements with Rust code it doesn't mean absolute safety is guaranteed. For him as a kernel guy just as when you double free the kernel C code detects it and warns about it Rust will panic abort on overflows/alloc fails etc. To the kernel that is not safety at all - as he points out it is only more debuggable.

He is allowing Rust in the kernel so he understands the fact that Rust allows you to shoot yourself in the foot a lot less than standard C - he is merely pointing out the reality that in kernel space or even user space that does not equate to absolute total safety. And as a chief kernel maintainer he is well within his rights to set the expectation straight that tomorrow's kernel-rust programmers write code with this point in mind.

(IOW as an example he doesn't want to see patches in Rust code that ignore kernel realities for Rust's magical safety guarantee - directly or indirectly allocating large chunks of memory may always fail in the kernel and would need to be accounted for even in Rust code.)

Re: “Rust is safe” is not some kind of absolute guarantee of code safety

#80

Post by magicalhippo »

kweingar wrote: post #47

Classic Linus. From the closing paragraph, I feel like he’s under the impression that Rust-advocating contributors are putting Rust’s interests (e.g. “legitimizing it” by getting it in the kernel) above the kernel itself.

> I feel like he’s under the impression that Rust-advocating contributors are putting Rust’s interests (e.g. “legitimizing it” by getting it in the kernel) above the kernel itself.

I mean the post Linus initially responded to did contain[1] a patch removing a kernel define, asking if anyone had any objections over removing that define, just to make the resulting Rust code a little nicer looking.

[1]: https://lkml.org/lkml/2022/9/19/640

Post reply on HN