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

181–190 of 542 posts

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

#181

Post by tmtvl »

staticassertion wrote: post #14

> 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, I don't know what to say. When people say "safe" there's a pretty precise meaning and it's not this. Yes, anyone who believes rust is 100% "safe" (by any definition) is wrong. That's not something you learn in Kindergarten though, i…

It does make sense that the mainline developers don't know what "safe" means if you arbitrarily decide that "safe" means "memory safe" specifically and no other kind of "safe". A Haskell or Clojure developer could arbitrarily decide that "safe" means "safe from side effects," but unless that is clearly stated every time they engage in discourse with someone I wouldn't blame their discussion partners for not knowing what the developer means when they talk about some code being "safe".

I will agree with you that I dread Rust in the kernel, hopefully it can continue to exist there peacefully without people getting too hot under the collar about their personal hang-ups. For all its flaws Rust has an amazing value prop in the borrow checker and I would love for memory bugs to be eliminated for good.

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

#182

Post by [deleted] »

EdSchouten wrote: post #138
jmillikin wrote: post #81

As usual HN comments react to the headline, without reading the content. A lot of modern userspace code, including Rust code in the standard library, thinks that invariant failures (AKA "programmer errors") should cause some sort of assertion failure or crash (Rust or Go `panic`, C/C++ `assert`, etc). In the kernel, claims Linus, failing loudly is worse than trying to keep going because failing would also kill the fa…

The policy of ‘oopsing’ and limping on is, in my opinion, literally one of Linux’s worst features. It has bitten me in various cases: - Remember when Linux had that caused the kernel to partially crash and eat 100% CPU due to some bug in the leap second application code? That caused a >1MW spike in power usage at Hetzner at the time. That must have been >1GW globally. Many people didn’t notice it immediately, so it m…

[deleted]

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

#183

Post by pornel »

lifthrasiir wrote: post #162
pornel wrote: post #102

Earlier quoted context omitted.

It's an unproductive pedantry to expect every mention of the generalisation to be followed by a full disclaimer about exceptions and edge cases. People say "it's raining" without having to add "except under roofs".

I think, if the wording was exactly "Rust is safe" it is indeed too vague as there are many notions of safety, and annoyingly enough people do say this. But "Rust provides memory safety" is clear enough and doesn't need further quantification.

Official Rust materials are careful not to overpromise and to be clear on the extent of what is guaranteed and what isn't.

The safety is always with an asterisk. Rust provides memory safety — provided that unsafe blocks, FFI, and other code running in the same process, and the OS itself, and the hardware doesn't misbehave.

But if you accept that Python and Java can be called safe languages then Rust can be too. The other ones also have unsafe escape hatches and depend on their underlying implementations to be correct to uphold safety for their safe side.

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

#184

Post by a_humean »

LtWorf wrote: post #118
a_humean wrote: post #77

Earlier quoted context omitted.

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.

Or, in other words, rust-safety should mean what safety means in every other context, or rust people need to come up with a different word.

You don't get to change the definition of a term used by another when it had a clear meaning in its use, and then make an arugment on the basis that the author meant y when they clearly meant x. That is just conflation.

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

#185

Post by KerrAvon »

SanjayMehta wrote: post #120
mynameisvlad wrote: post #39

Earlier quoted context omitted.

That shouldn’t excuse him from being a reasonably decent person to work with. He gets a lot more leeway than being the creator of Linux should afford someone.

Unreasonable people build things. Reasonable people run meetings.

I have no opinion on Linus’s behavior here, but that is both false and toxic. Steve Jobs only became truly effective when he learned to be reasonable in appropriate contexts. People who remain unreasonable all of the time crater their companies in the long run. Every time.

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

#186

Post by SanjayMehta »

mynameisvlad wrote: post #146
SanjayMehta wrote: post #120

Earlier quoted context omitted.

Unreasonable people build things. Reasonable people run meetings.

Reasonable people also build things. Unreasonable people also build things alone where everyone else doesn’t have to deal with them. The world is hardly as black and white as you make it seem.

There are 10 kinds of people. Those who understand binary and those who don't.

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

#187

Post by Veliladon »

layer8 wrote: post #154
dcsommer wrote: post #139

Earlier quoted context omitted.

> ... the general Rust practice of panicking upon unexpected conditions What makes you say this? From the sample I've seen, Rust programs are far more diligent about handling errors (not panicking: either returning error or handling it explicitly) than C or Go programs due to the nature of wrapped types like Option and Result . You can't escape handling the error, and panicking potential is very easy to see and lint…

I’m referring to the fact that ubiquitous functions like unwrap() panic if the programmer has made an error. Guarding against such panics is outside of the scope of Rust-the-language, and has to be handled through external means. There are linters for C as well.

I think I prefer Rust's way of doing things. Just last night I used the Vec! macro incorrectly putting in a comma instead of a semi-colon and despite the program compiling correctly, it immediately panicked with an OOB error. With C it would have been a lot harder to even notice a bug little alone track it down.

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

#188

Post by Someone1234 »

ChrisSD wrote: post #71
arinlen wrote: post #63

Earlier quoted context omitted.

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

This question is answered in Linus' emails fully and better than I'm going to do.

But to restate briefly, the answer varies wildly between kernel and user programs, because a user program failing hard on corrupt state is still able to report that failure/bug, whereas a kernel panic is a difficult to report problem (and breaks a bunch of automated reporting tooling).

So in answer: Read the discussion.

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

#189

Post by elteto »

charcircuit wrote: post #114
zetaposter wrote: post #26

Earlier quoted context omitted.

Yeah ... Just reboot the machine and make me loose all my work, bro.

This is why programs automatically saving their state is important.

No, this is why kernels prioritizing not crashing is important. Applications saving their work is a nice extra.

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

#190

Post by roywiggins »

geraneum wrote: post #128
layer8 wrote: post #99

Earlier quoted context omitted.

Please correct me if I’m wrong, but Rust also has no built-in mechanism to statically determine “this code won’t ever panic”, and thus with regards to Linux kernel requirements isn’t safer in that aspect than C. To the contrary, Rust is arguably less safe in that aspect than C, due to the general Rust practice of panicking upon unexpected conditions.

We cannot ensure that an arbitrary program halts by statically analyzing it. And it doesn’t have anything to do with the language of choice. https://en.m.wikipedia.org/wiki/Halting_problem

You can prove that a machine can't ever write "1" to the tape if you just look at the state machine and see that none of the rules write a 1 to the tape. Since no rules ever write 1, no possible execution could.

Working out whether it will write 1 to the tape in general is undecidable, but in certain cases (you've just banned states that write 1) it's trivial.

If all of the state transitions are valid (a transition to a non-existing state is a halt) then the machine can't get into a state that will transition into a halt, so it can't halt. That's a small fraction of all the machines that won't halt, but it's easy to tell when you have one of this kind by looking at the state machine.

Post reply on HN