“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

#201

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

h2odragon wrote: post #149

mustache_kimono wrote: post #115

Earlier quoted context omitted.

At least they don't go around slandering programming language communities. If we're going to be serious about who is being toxic, it's definitely Linus in this thread. Guy makes first mistake (by a very broad interpretation of "mistake". Perhaps "misunderstanding"?). Linus goes nuclear. And while his reasoning is sound, his argumentation cycles between threats, bad-faith arguments, and just plain old yelling. What so…

Threats? Slander? Do you feel that you're "speaking for a community" here?

Heck no! And I can't imagine anyone thinking I was?

The threat is pretty clear? "If Rust people don't get this, we will have to part ways." This is an ultimatum? It's crazy girlfriend/boyfriend material? It's ridiculous after one contributor tries something that Linus thinks won't work in the kernel. Ridiculous. Just say no.

The slander as well? "Rust’s community, in aggregate, have developed a reputation." And you know what? The C/C++/Zig/Nim/Haskell/Clojure communities have developed a reputation too, but, gosh, I don't talk about it because I know labeling groups isn't helpful/is completely non-technical.

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

#202

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

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…

So instead of a power spike, we'd have had a major internet outage across the world, across the entire industry and beyond, probably, if everyone had panicked on oops. The blame really lies with people not monitoring their systems.

As you said, you have the option to reboot on panic, but Linus is absolutely not wrong that this size does not fit all.

What about a medical procedure that WILL kill the patient if interrupted? What about life support in space? Hitting an assert in those kinds of systems is a very bad place to be, but an automatic halt is worse than at least giving the people involved a CHANCE to try and get to a state where it's safe to take the system offline and restart it.

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

#203

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

tmtvl wrote: post #181

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

>if you arbitrarily decide that "safe" means "memory safe" specifically and no other kind of "safe".

This is how Rust has always defined it. Linus is specifically saying that "Rust people" don't understand what "safe" is but... they do, he doesn't. He could say "Rust defines it as X, the kernel needs Y" but he doesn't say that, he implies that Rust people just don't understand the word "safe" or that they think Rust is safer than it is, which is simply not true. As I said, quite ironic given history.

> I wouldn't blame their discussion partners for not knowing what the developer means when they talk about some code being "safe".

I mean, I would definitely blame them if they're also going to go on an insulting rant about their definition being wrong.

> without people getting too hot under the collar about their personal hang-ups

Impossible, in my opinion, until a ton of people retire.

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

#204

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

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.

Linters can catch panics, linters for C won't catch memory issues which is what rust prevents.

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

#205

Post by hedgehog » Sun, Oct 02, 2022, 4:22 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…

As I read it the issue is a little bit deeper, start with the context here and read down the thread:

https://lkml.org/lkml/2022/9/19/640

Get at least down to here:

https://lkml.org/lkml/2022/9/20/1342

What Linus seems to be getting at is that there are many varying contextual restrictions on what code can do in different parts of the kernel, that Filho etc appear to be attempting to hide that complexity using language features, and that in his opinion it is not workable to fit kernel APIs into Rust's common definition of a single kind of "safe" code. All of this makes sense, in user land you don't normally have to care about things like whether different functional units are turned on or off, how interrupts are set up, etc, but in kernel you do. I'm not sure if Rust's macros and type system will allow solving the problem as Linus frames it but it seems like a worthy target & will be interesting to watch.

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

#206

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

tialaramex wrote: post #132

I don't think I buy Linus' high level claim. It is not necessarily better to press on with the wrong answer, in some cases failure actually is an option and might be much better than oops we did it wrong. This morning I was reading about the analysis of an incident in which a London tube train drove away with open doors. Nobody was harmed, or even in immediate danger, the train had relatively few passengers and in fa…

I feel like the OP is really hurting from quoting Linus out of context. This is many messages deep in a thread about automatically detecting atomic contexts in the allocator.

And I don’t think he’s making a system level claim, that the whole train system should be designed to limp on through failures. He’s claiming that the kernel needs to be able to limp on so that the systems that use it can have the best chance of e.g. sending automated bug reports. (Or you can turn off the limping behavior if you want; maybe trains should do that. But maybe a train’s control system randomly rebooting might be more catastrophic than leaving its doors open? I don’t know.)

From a couple messages up-thread in the OP:

> … having behavior changes depending on context is a total disaster. And that's invariably why people want this disgusting thing.

They want to do broken things like "I want to allocate memory, and I don't want to care where I am, so I want the memory allocator to just do the whole GFP_ATOMIC for me".

And that is FUNDAMENTALLY BROKEN.

If you want to allocate memory, and you don't want to care about what context you are in, or whether you are holding spinlocks etc, then you damn well shouldn't be doing kernel programming. Not in C, and not in Rust.

It really is that simple. Contexts like this ("I am in a critical region, I must not do memory allocation or use sleeping locks") is fundamental to kernel programming. It has nothing to do with the language, and everything to do with the problem space.

So don't go down this "let's have the allocator just know if you're in an atomic context automatically" path. It's wrong. It's complete garbage. It may generate kernel code that superficially "works", but one that is fundamentally broken, and will fail and becaome unreliable under memory pressure

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

#207

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

mustache_kimono wrote: post #115

sidlls wrote: post #68

Earlier quoted context omitted.

They probably are, in many cases. Rust’s community, in aggregate, have developed a reputation (earned, in my opinion). It’s too bad that the community don’t follow the leaders’ example in this regard. There are some quality, level-headed Rust advocates. They appear to be the minority.

At least they don't go around slandering programming language communities. If we're going to be serious about who is being toxic, it's definitely Linus in this thread. Guy makes first mistake (by a very broad interpretation of "mistake". Perhaps "misunderstanding"?). Linus goes nuclear. And while his reasoning is sound, his argumentation cycles between threats, bad-faith arguments, and just plain old yelling. What so…

It might be difficult to back out kernel changes versus userspace changes. App-level concerns with leaky abstractions could follow functional programming, immutable state, fail-fast, and all sorts of gospel--but there's still a kernel doing stuff behind the scenes.

If the kernel acquiesces to certain philosophies that are opposite to its intent as-a-kernel for many other environments and contexts it must support, a cascade of later patches could derail things completely. It may become too much effort to undo, and the project must limp along--until that mountain of tech debt costs too much to fix.

Maybe the kernel cannot fail fast for good reasons. And the Linux project cannot fail fast for equally good reasons.

And possibly, if a technically compelling reason presents itself, Linus may fully back it--even contributing to that work himself.

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

#208

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

Veliladon wrote: post #187

layer8 wrote: post #154

Earlier quoted context omitted.

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.

Right. My personal opinion is that exceptions provide a better trade-off between catching bugs and still allowing the chance of graceful shutdown or recovery.

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

#209

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

layer8 wrote: post #199

pornel wrote: post #122

Earlier quoted context omitted.

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…

One has to be careful about words. When Rust (or Linux) is used in (say) a vehicle or in a nuclear power plant, panicking certainly has immediate safety implications.

But it can still be safer - e.g. a panic can trigger an emergency stop instead of silently overwriting the "go full throttle" variable.

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

#210

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

charcircuit wrote: post #107

atty wrote: post #25

Earlier quoted context omitted.

The kernel can’t fail to complete its operations, because then the entire system crashes and no logs are created. Instead, you can finish the operation and check the result.

panic doesn't instantly crash the program. It prints out debug information first. You could have kernel panics work the same way.

And when Linux is running on your fridge, in your car, or on a headless VM then who is there to read out this "printed output." The great thing about "log and continue" is you can automate collection and fix the underlying bug (or know that the hardware is failing).

Keep in mind that in a kernel panic no hardware is assumed to work, so assumptions like "just write to storage!" isn't an assumption you can make, you're in a panic the IO could have been literally pulled out.