“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

#381

Post by vlovich123 » Sun, Oct 02, 2022, 7:04 PM UTC

ok123456 wrote: post #288

znpy wrote: post #230

Earlier quoted context omitted.

> They occupy less than 1% of the programming community and act like they single-handedly are the only people who understand correctness. Maybe I’m too young (just past 30) but is it just me or is that some kind of attitude that emerged in the last 10-15 years? And I mean not only in programming, but in general. A small amount of people which is very vocal about something and start pushing everybody else to their thi…

>A small amount of people which is very vocal about something and start pushing everybody else to their thing while simultaneously shaming and/or making fun of those who either disagree or aren’t generally interested. It's called manufacturing consent and it's all around us.

That’s extremely ungenerous. I see the legitimate challenges with Rust as do most people I talk with who are C++ veterans. But we also all agree that C/C++ isn’t tenable in the long term. It might not be Rust that wins eventually but only because a better alternative pops up. Without a better alternative it’s going to be Rust. And let me tell you. The Rust team to date has been very good at building a very attractive ecosystem and bringing people along. The people who are Rust advocates that I’ve come across tend to be extremely thoughtful individuals and not just fanboys latching onto something cool.

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

#382

Post by maxbond » Sun, Oct 02, 2022, 7:04 PM UTC

flumpcakes wrote: post #275

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 think it's obvious that Linus is correct here. For example, say there's a bug in the Linux kernel that would produce a "panic" at midnight Dec 31st 2022... do we accept a billion devices shutting down? In the best case rebooting and resuming a whatever user space program was running? Despite the bad taste, I think the obvious answer is as Linus says: the Kernel should keep going despite errors.

A better analogy would be: Let's say if we have kernel A that contains a bug; we don't know when it will trigger or what it will do. We have another kernel, B, which has the same bug, but while we don't know when it will trigger, we know it will cause the device to halt. Which is the better kernel?

I'd say B is nearly always the better choice, because halting is a known state it's almost always possible to recover from, and going into unknown state may cause you to get hacked or to damage your peripherals. But if we were operating, say, a Mars rover, and shutting down meant we would never be able to boot again, then it'd be better take kernel A and attempt to recover from whatever state we find ourselves in. That's pretty exotic, however.

In the case of an unanticipated error in a software component, we always need input from an external source to correct ourselves. When you're the kernel, that generally means either a human being or a hypervisor has to correct you; better to do so from a halted state than an entirely unknown one. Trying to muddle through despite is super dangerous, and makes your software component into lava in the case of a fault.

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

#383

Post by stjohnswarts » Sun, Oct 02, 2022, 7:05 PM UTC

pornel wrote: post #245

hegelstoleit wrote: post #215

Earlier quoted context omitted.

I think you're missing the point Linus made. Panicking is safer from a memory safety perspective, but it's not from a kernel perspective. You'll lose all the file changes that are not saved, you'll risk having disk written in a bad state which can be catastrophic, etc.

I understand his point. I just disagree, and prefer a different tradeoff. Yes, a kernel panic will cause disruption when it happens. But that will also give a precise error location, which makes reporting and fixing of the root cause easier. It could be harder to pinpoint of the code rolled forward in broken state. It will cause loss of unsaved data when it happens, but OTOH it will prevent corrupted data from being…

On one embedded projected we had a separate debug chip could safely shutdown what might be dangerous circuits in the case of controller failure. The source code for that was much much much smaller than the controller and heavily vetted by mulitiple people. The small dedicated would initiate circuit shutdown on panic from the linux kernel on the controller. My point being is it's hard to know what happens after a panic, and logging and such is nice, but that may or may not be available, but being able to do some action as simple as sending a "panic" signal to a second dedicated processor to shut down critical systems in a controlled manner is nice. "Stop the world" can be very dangerous in some situations. There were even more independent backup failsafes on the potentially dangerous circuits as well, but redundancy is even more insurance something bad won't happen.

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

#384

Post by notacoward » Sun, Oct 02, 2022, 7:10 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…

Yeah, this part has never really been true.

> In the kernel, "panic and stop" is not an option

That's simply not true. It's an option I've seen exercised many times, even in default configurations. Furthermore, for some domains - e.g. storage - it's the only sane option. Continuing when the world is clearly crazy risks losing or corrupting data, and that's far worse than a crash. No, it's not weird to think all types of computation are ephemeral or less important than preserving the integrity of data. Especially in a distributed context, where this machine might be one of thousands which can cover for a transient loss of one component but letting it continue to run puts everything at risk, rebooting is clearly the better option. A system that can't survive such a reboot is broken. See also: Erlang OTP, Recovery Oriented Computing @ Berkeley.

Linus is right overall, but that particular argument is a very bad one. There are systems where "panic and stop" is not an option and there are systems where it's the only option.

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

#385

Post by stjohnswarts » Sun, Oct 02, 2022, 7:12 PM UTC

mike_hock wrote: post #268

pornel wrote: post #209

Earlier quoted context omitted.

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

Yes, or jumping to the "emergency stop" routine can instead trigger "go full throttle" because the jump address has been corrupted. Or in an actual vehicle, the "emergency stop" (if that means just stomping on the brakes) can flip the car and kill its passengers.

It's about the odds here. Nothing is 100% safe. Independent systems almost always provide backup safety incase the OS/embedded system fails. Thing like overcurrent detector, brown out detectors, speed governors, etc in case code does something as a result of running corrupted (or something similarly awful)

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

#386

Post by notacoward » Sun, Oct 02, 2022, 7:13 PM UTC

mike_hock wrote: post #202

EdSchouten wrote: post #138

Earlier quoted context omitted.

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

> What about a medical procedure that WILL kill the patient if interrupted? What about life support in space?

The proper answer to those is redundancy, not continuing in an unknown and quite likely harmful state.

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

#387

Post by stjohnswarts » Sun, Oct 02, 2022, 7:13 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.

That's where linters and code reviews come in, you will never 100% prevent stupid coding, that's where review either automated and/or other coders and coding standards come in.

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

#388

Post by stjohnswarts » Sun, Oct 02, 2022, 7:14 PM UTC

layer8 wrote: post #208

Veliladon wrote: post #187

Earlier quoted context omitted.

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.

exceptions would be awful in the kernel. I would be highly surprised if kernels like fuscia allow c++ exceptions.

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

#389

Post by wtallis » Sun, Oct 02, 2022, 7:14 PM UTC

maxbond wrote: post #382

flumpcakes wrote: post #275

Earlier quoted context omitted.

I think it's obvious that Linus is correct here. For example, say there's a bug in the Linux kernel that would produce a "panic" at midnight Dec 31st 2022... do we accept a billion devices shutting down? In the best case rebooting and resuming a whatever user space program was running? Despite the bad taste, I think the obvious answer is as Linus says: the Kernel should keep going despite errors.

A better analogy would be: Let's say if we have kernel A that contains a bug; we don't know when it will trigger or what it will do. We have another kernel, B, which has the same bug, but while we don't know when it will trigger, we know it will cause the device to halt. Which is the better kernel? I'd say B is nearly always the better choice, because halting is a known state it's almost always possible to recover fr…

> But if we were operating, say, a Mars rover, and shutting down meant we would never be able to boot again, then it'd be better take kernel A and attempt to recover from whatever state we find ourselves in. That's pretty exotic, however.

That you view it as exotic is partly a lack of imagination on your part; with a little more effort it's possible to identify similar use cases that are much closer to home than Mars.

But that doesn't really matter. What matters is that the Linux kernel needs to support both options, because it's just one component in a larger system and that context outside the kernel is what determines which option is correct for that system.

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

#390

Post by wtallis » Sun, Oct 02, 2022, 7:19 PM UTC

notacoward wrote: post #384

EdSchouten wrote: post #138

Earlier quoted context omitted.

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…

Yeah, this part has never really been true. > In the kernel, "panic and stop" is not an option That's simply not true. It's an option I've seen exercised many times, even in default configurations. Furthermore, for some domains - e.g. storage - it's the only sane option. Continuing when the world is clearly crazy risks losing or corrupting data, and that's far worse than a crash. No, it's not weird to think all types…

> Furthermore, for some domains - e.g. storage - it's the only sane option.

Can you elaborate on this? Because failing storage is a common occurrence that usually does not warrant immediately crashing the whole OS, unless it's the root filesystem that becomes inaccessible.