“Rust is safe” is not some kind of absolute guarantee of code safety • Hacker News Board

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

#151

Post by VancouverMan » Sun, Oct 02, 2022, 4:02 PM UTC

ukweld wrote: post #70

coldtea wrote: post #61

> And the reality is that there are no absolute guarantees. Ever. The "Rust is safe" is not some kind of absolute guarantee of code safety. Never has been. Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus. I thought that he had apologised and regretted being hostile in comments. Apparently not. Not that I have much of an issue with ranty…

Why are so many people criticizing Linus? This post strikes me as relatively moderate. Other software dictators do exactly the same, but in a more underhanded and bureaucratic manner, which is worse. Yet their disciples call them "benevolent". I can deal with Linus, but not with the latter. Linus strikes me as not being really serious or vindictive. It's just a colorful way of expressing himself.

No post body was provided.

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

#152

Post by im3w1l » Sun, Oct 02, 2022, 4:02 PM UTC

jrochkind1 wrote: post #126

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.

> but Rust also has no built-in mechanism to statically determine “this code won’t ever panic”, My intuition says that's the Halting Problem, so not actually possible to implement perfectly? https://en.wikipedia.org/wiki/Halting_problem

If you are fine with saying that stuff like this code may panic (and many people are fine with just that), then it's perfectly doable

    if false {
        panic!()
    }

Basically you'd prohibit any call to panic whether they may actually end up running or not.

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

#153

Post by dureuill » Sun, Oct 02, 2022, 4:02 PM UTC

Hmmm, the linked email is not providing a lot of context, so surely I'm missing something, but there's something I definitely don't understand: is there not a third option between stopping the whole kernel on an error or allowing an incorrect result?

Maybe my misunderstanding comes from my ignorance of the kernel's architecture, but surely there's a way to segregate operations in logical fallible tasks, so that a failure inside of a task aborts the task but doesn't put down the entire thing, and in particular not a sensitive part like kernel error reporting? Or are we talking about panics in this sensitive part?

Bubbling up errors in fallible tasks can be implemented using panic by unwrapping up to the fallible task's boundary.

To my understanding this is exactly what any modern OS does with user space processes?

I always have the hardest of time in discussions with people advocating for or against that "you should stop computations on an incorrect result". Which computations should you stop? Surely, we're not advocating for bursting the entire computer into flames. There has to be a boundary. So, my take is to start defining the boundaries, and yes, to stop computations up to these boundaries.

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

#154

Post by layer8 » Sun, Oct 02, 2022, 4:03 PM UTC

dcsommer wrote: post #139

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.

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

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

#155

Post by aspaceman » Sun, Oct 02, 2022, 4:04 PM UTC

titzer wrote: post #140

blinkingled wrote: post #79

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

If that's what Linus is saying, then he needs to work on his communication skills, because that is not what he said. What he actually said is that dynamic errors should not be detected, they should be ignored . That's so antiquated and ignorant that I hope that he meant what you said, but it's definitely not what he wrote. As I posted up in this thread, the right way to handle this is to make dynamic errors either th…

> it's definitely not what he wrote.

I feel like we must have read two different articles. You sound crazy. Didn't read it your way at all.

> Think of that "debugging tools give a huge warning" as being the equivalent of std::panic in standard rust. Yes, the kernel will continue (unless you have panic-on-warn set), because the kernel MUST continue in order for that "report to upstream" to have a chance of happening.

"If the kernel shuts down the world, we don't get the bug report", seems like a pretty good argument. There are two options when you hit a panic in rust code:

* Panic and shut it all down. This prevents any reporting mechanism like a core dump. You cannot attach a normal debugger to the kernel.

* Ignore the panic and proceed with the information it failed, reporting this failure later.

The kernel is a single program, so it's not like you could just fork it before every Rust call and fail if they fail.

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

#156

Post by skybrian » Sun, Oct 02, 2022, 4:04 PM UTC

jrochkind1 wrote: post #126

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.

> but Rust also has no built-in mechanism to statically determine “this code won’t ever panic”, My intuition says that's the Halting Problem, so not actually possible to implement perfectly? https://en.wikipedia.org/wiki/Halting_problem

That's different. You can't perfectly detect all infinite loops in a language that allows arbitrary loops. This also means you can't perfectly detect unreachable code.

But determining that a function (such as panic) is never called because there are no calls to it is pretty easy.

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

#157

Post by [deleted] » Sun, Oct 02, 2022, 4:05 PM UTC

jrochkind1 wrote: post #126

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.

> but Rust also has no built-in mechanism to statically determine “this code won’t ever panic”, My intuition says that's the Halting Problem, so not actually possible to implement perfectly? https://en.wikipedia.org/wiki/Halting_problem

[deleted]

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

#158

Post by titzer » Sun, Oct 02, 2022, 4:05 PM UTC

aspaceman wrote: post #155

titzer wrote: post #140

Earlier quoted context omitted.

If that's what Linus is saying, then he needs to work on his communication skills, because that is not what he said. What he actually said is that dynamic errors should not be detected, they should be ignored . That's so antiquated and ignorant that I hope that he meant what you said, but it's definitely not what he wrote. As I posted up in this thread, the right way to handle this is to make dynamic errors either th…

> it's definitely not what he wrote. I feel like we must have read two different articles. You sound crazy. Didn't read it your way at all. > Think of that "debugging tools give a huge warning" as being the equivalent of std::panic in standard rust. Yes, the kernel will continue (unless you have panic-on-warn set), because the kernel MUST continue in order for that "report to upstream" to have a chance of happening.…

He wrote:

> In the kernel, "panic and stop" is not an option (it's actively worse than even the wrong answer, since it's really not debugable), so the kernel version of "panic" is "WARN_ON_ONCE()" and continue with the wrong answer.

(edit, and):

> Yes, the kernel will continue (unless you have panic-on-warn set), because the kernel MUST continue in order for that "report to upstream" to have a chance of happening.

Did I read that right? The kernel must continue? Yes, sure, absolutely...but maybe it doesn't need to continue with the next instruction, but maybe in an error handler? Is his thinking so narrow? I hope not.

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

#159

Post by WastingMyTime89 » Sun, Oct 02, 2022, 4:05 PM UTC

Test0129 wrote: post #100

flohofwoe wrote: post #85

Earlier quoted context omitted.

> Rust is not an absolute guarantee of safety and doesn’t protect us from all the bugs. That's not exactly the vibe I'm getting from the typical Rust fanboys popping up whenever there's another CVE caused by the usage of C or C++ though ;) Rust does seem to attract the same sort of insufferable personalities that have been so typical for C++ in the past. Why that is, I have no idea.

I wouldn't say the Rust community parallels the C++ community in any way. The rust community is more like the insufferable Haskell/FP community who, despite producing very little measurable commercial value continue to look down on everyone else. Indeed, there's a lot of damage control going on in this thread walking back Rust's guarantees of safety despite that, up until this point, being Rust's only real selling po…

> Haskell/FP community

As someone who worked on a lot of OCaml projects, I would like to assure you that the issue really is the Haskell community which I too find completely unbearable. The rest of the FP community is far nicer/less smug.

For a long time, they just thought it was a shame some innovative constructs seemed to be stuck in their favourite languages (first class functions, variant types, inference) and not percolating to the mainstream. This fight has mostly be won which is great.

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

#160

Post by pca006132 » Sun, Oct 02, 2022, 4:05 PM UTC

jrochkind1 wrote: post #126

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.

> but Rust also has no built-in mechanism to statically determine “this code won’t ever panic”, My intuition says that's the Halting Problem, so not actually possible to implement perfectly? https://en.wikipedia.org/wiki/Halting_problem

No, panic is not halting, you just need some static check to check that you never call some functions that can panic in your code. Essentially it is just checking if some code (panic) might be reachable, if it is not, it will never panic (but it can still do other crazy things).

Note that we can only check for maybe, because in general we don't know if some code in the middle will somehow execute forever and never reach the panic call after it.