“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

#121

Post by swinglock » Sun, Oct 02, 2022, 3:49 PM UTC

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…

At least in user space, aborting an operation is much better than incorrect results. But the kernel being incorrect makes user space incorrect as well.

First of all, making a problem both obvious and easier to solve is better. Nothing "only" about it - it's better. Better both for the programmers and for the users. For the programmer the benefit is obvious, for the user problems will simply be more rare, because the benefit the programmer received will make software better faster.

Second, about the behavior. When you attempt to save changes to your document, would you rather have the corruption of your document due to a bug fail with fanfare or succeed silently? How about the web page you visited with embedded malicious JavaScript from a compromised third party, would you rather the web page closed or have your bank details for sale on a foreign forum? When correctness is out the window, you must abort.

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

#122

Post by pornel » Sun, Oct 02, 2022, 3:49 PM UTC

layer8 wrote: post #99

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…

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.

Lack of a non-hacky no-panic guarantee is a pain. That would be like a no-segfault guarantee in C.

But Rust's situation is still safer, because Rust can typically prevent more errors from ever becoming a run-time issue, e.g. you may not even need to use array indexing at all if you use iterators. You have a guarantee that references are never NULL, so you don't risk nullptr crash, etc.

Rust panics are safer, because they reliably happen instead of an actually unsafe operation. Mitigations in C are usually best-effort and you may be lucky/unlucky to silently corrupt memory.

Panics are a problem for uptime, but not for safety (in the sense they're not exploitable for more than DoS).

In the long term crashing loud and clear may be better for reliability. You shake out all the bugs instead of having latent issues that corrupt your data.

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

#123

Post by jmull » Sun, Oct 02, 2022, 3:49 PM UTC

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…

> The point he makes is BS. "the reality is that there are no absolute guarantees. Ever" Yeah, DUH!

You calling his point BS, but also strongly agreeing with it.

I guess you find it too obvious. But while it's obvious to many, there seem to be many who do not understand it. Issues involving rust often get derailed to pointlessness when rust's safety guarantees are treated as an absolute.

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

#124

Post by jmillikin » Sun, Oct 02, 2022, 3:50 PM UTC

Tomte wrote: post #64

I actually wondered with all the recent "Rust in the kernel" about culture clashes. I mean, most kernel developers aren't Rust programmers (and vice versa). Now we got a first glimpse at what happens. Still, I find it strange that it never seemed to come up in preparation to the first Rust merges. Were there any conflict resolution strategies in place (that I don't know about) or just "we flame it out on LKML"?

I think this is more "[modern] userspace vs kernel" than "Rust vs kernel".

If you dig slightly below the surface in any major userspace codebase, it has abort paths everywhere. Every memory allocation might abort, every array index or dict lookup might throw an exception, which if uncaught will abort. Lock (or unlock) a mutex twice, abort.

The Rust standard library inherited this philosophy in large and small ways. An easy example (already being addressed) is memory allocation, but less obvious is stuff like "integer math is allowed to panic on overflow". It's not easy to write Rust code that is guaranteed not to panic in any branch.

Now the userspace-trained Rust folks are working in the kernel, and they want to be able to panic() when something goes horribly wrong, but that's not how the kernel code works. They'd have the same issue if you tried to get a bunch of GNOME contributors to write kernel drivers with GLib, even though GLib is pure C.

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

#125

Post by remram » Sun, Oct 02, 2022, 3:52 PM UTC

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.

Not completing the operation is also a security issue, commonly called denial of service (DoS).

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

#126

Post by jrochkind1 » Sun, Oct 02, 2022, 3:52 PM UTC

layer8 wrote: post #99

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…

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

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

#127

Post by titzer » Sun, Oct 02, 2022, 3:53 PM UTC

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 way to handle this is split up kernel work into fail-able tasks [1]. When a safety check (like array OOB) occurs, it unwinds the stack up to the start of the task, and the task fails.

Linus sounds so ignorant in this comment. As if no one else thought of writing safety-critical systems in a language that had dynamic errors, and that dynamic errors are going to bring the whole system down or turn it into a brick. No way!

Errors don't have to be full-blown exceptions with all that rigamarole, but silently continuing with corruption is utter madness and in 2022 Linus should feel embarrassed for advocating such a backwards view.

[1] This works for Erlang. Not everything needs to be a shared-nothing actor, to be sure, but failing a whole task is about the right granularity to allow reasoning about the system. E.g. a few dozen to a few hundred types of tasks or processes seems about right.

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

#128

Post by geraneum » Sun, Oct 02, 2022, 3:54 PM UTC

layer8 wrote: post #99

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…

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

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

#129

Post by throw827474737 » Sun, Oct 02, 2022, 3:55 PM UTC

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?

Had the same topic often on MCUs: limp along to hopefully get the error out somehow, otherwise it won't be noticed if not with JTAG debugger attached (default in field).

So I can understand where Linus comes from.

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

#130

Post by jmillikin » Sun, Oct 02, 2022, 3:55 PM UTC

layer8 wrote: post #99

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…

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.

Rust doesn't have an official `#[never_panic]` annotation, but there's a variety of approaches folks use. Static analysis (Clippy) can get you pretty far. My favorite trick is to link a no_std binary with no panic handler, and see if it has a linker error. No linker error = no calls to panic handler = no panics.

Note that Rust is easier to work with than C here, because although the C-like API isn't shy about panicking where C would segfault, it also inherits enough of the OCaml/Haskell/ML idiom to have non-panic APIs for pretty much any major operation. Calling `saturating_add()` instead of `+` is verbose, but it's feasible in a way that C just isn't unless you go full MISRA.