Live data from Hacker News

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

lkml.org

251–260 of 542 posts

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

#251
post #242

Earlier quoted context omitted.

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? 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. Kinda a strawman there. That's got to account for, what, 0.0001% of all u…

Do you know absolutely every medical device in existence and do you know how broad the definition of a medical device is (including e.g. the monitor attached to the PC used for displaying X-ray images)?

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

#252
post #224

Earlier quoted context omitted.

If you were to define a subset of Rust's standard library (core + alloc + std) that does not contain the `panic!` macro, and excluded all functionality that needed to panic, then safe Rust could be proven to never panic (because it can't). That's different than solving the halting problem. You're not trying to prove it halts, you're just trying to prove it doesn't halt in a specific way, which is trivial to prove if…

> If you were to define a subset of Rust's standard library (core + alloc + std) that does not contain the `panic!` macro, and excluded all functionality that needed to panic, then safe Rust could be proven to never panic (because it can't). Not quite, because stack overflows can cause panics independent of any actual invocation of the panic macro. You need to either change how stack overflows are handled as well, or…

In a Rust defined without `panic!`, a stack overflow would not be able to panic. What would probably happen is the process would just die, like C.

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

#253

Earlier quoted context omitted.

>work environments It’s not a “work environment”. You can’t report Linus to HR. If you have a problem with him, you can fork the kernel and convince others to follow you. Then you’ll have a mailing list where you can ban Linus for his style. Good luck!

Yes because if he were at any company, he’d have been fired. Decades ago. Just because it’s not an official “work environment” per your definition does not mean it isn’t hostile or intolerable were it actually one. But actually countering that point is a lot harder, isn’t it?

> Yes because if he were at any company, he’d have been fired. Decades ago.

And then there would be no Linux kernel. So much for companies.

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

#254

I’ve been using Rust for a while, and I’m so, so tired of hearing this argument. Yes, we know. We get it. Rust is not an absolute guarantee of safety and doesn’t protect us from all the bugs. This is obvious and well-known to anyone actually using Rust. At this point, the argument feels like some sort of ideological debate happening outside the realm of actually getting work done. It feels like any time someone says…

Fwiw, the original article/email is less about "Rust has unsafe" and more about "panicking/crashing to avoid triggering UB isn't a viable strategy in the kernel."

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

#255

Earlier quoted context omitted.

It protects against the leading 70 percent of CVEs, which are due to memory safety issues. This is all Rust has ever claimed to solve and it's all I've ever seen anyone cite when advocating for it. If these people are insufferable to you, that I can't change your mind on. That said you might want to get used to it since major areas of industry are already considering C/C++ as deprecated (a paraphrasing from the Azure…

I didn't know the Azure CTO was the CTO was the C++ community. I'm sure the billions of lines of code written in C++ for the finance industry would love to have a word. The insufferable nature of the people isn't the advocating of safety. It's that Rust seems to have evolved a community of "X wouldn't have happened if Y was written in Rust!" and then walking away like they just transferred the one bit of knowledge ev…

This is not the first time it's happened. JS is effectively deprecated in favor of TS in the hearts of programmers in that ecosystem. There was a lot of disagreement about this a decade ago, but TS is now at its 10 year anniversary and any serious project in that world should be written with static type definitions. It had the early adopters that were insufferable at the time, but they were right about the path and those that have jumped in are having a way better experience.

I think history will show that we can do a lot better than C/C++ and Rust is one of the best steps yet to show that. Rust will be replaced by something better some day and the cycle will repeat.

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

#256

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…

There’s nothing to walk back since the post does not contest Rust’s safety guarantees at all. The link is (by design or not) effectively click bait “Linus Torvalds says that Rust is not really safe”, when in reality it is just him saying that panicky (panic on programmer error) Rust code is inappropriate for the kernel and that Rust-in-Linux code should by default limp on when it has encountered an error. That is a perfectly reasonable point to make, but has got nothing to do with “safety” in the sense that the Rust project talks about that term.

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

#257
post #158

Earlier quoted context omitted.

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

In the case of WARN() macros, it will be continued with whatever the code says. There is no automatic stack unwinding in the kernel, and how errors should be handled (apart from being logged) must be decided case-by-case. It could just be handled with an early-exit returning an error code, like other "more expected" errors.

The issue being discussed here is that Rust comes from a perspective of being able to classify errors and being able to automate error handling. In the kernel, it doesn't work like that, as we're working with more constraints than in userland. That includes hardware that doesn't behave like it was expected to.

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

#258
post #118

Earlier quoted context omitted.

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.

I think the word "safety" existed before rust…

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

#259
post #208

Earlier quoted context omitted.

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.

In my case it wouldn't have raised an exception though, it would have just been UB. It's not like there's not exceptions in Rust though. The error handling is thorough to a fault when it's used. Unwrap is just a shortcut to say "I know there might be bad input, I don't want to handle it right now, just let me do it and I'll accept the panic."

By exceptions, I’m referring to languages with exceptions as a dedicated language construct with automatic stack unwinding, and preferably without UB (e.g. Java or C#). Rust doesn’t have exceptions in that sense.

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

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

Prints it out how? If the kernel has crashed how do you guarantee anything gets printed, either to the screen, tty, log file?
Post reply on HN