“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

#271

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

pca006132 wrote: post #192

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…

Probably not very linux, but consider the case where a device is controlling a motor speed by setting its current, computed by getting its current speed and do a simple PID control. If your device crashed (due to failure of something else, for example some LED display) while the current output is pretty large, you may cause some serious damage to whatever that motor is connected to. The thing the system should be abl…

Such a device should have a simple protective circuit that doesn't allow this. This is common in any expensive or critical industrial system.

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

#272

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

pwinnski wrote: post #237

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…

Linus' statement are applicable to the kernel only, and if we're using tube analogies, he was talking more about situations where the train is underway and something fails. The Rust way would be to panic, train stops in between stations and must be rebooted to continue. Linus was saying no, you carry on despite the error until you get to the next station. Much as the passengers in your story did.

> The Rust way would be to panic, train stops in between stations and must be rebooted to continue.

Which is safe. It's inconvenient, but it's safe. Failures of this sort do happen, electrical fires are probably the most extreme example. They're annoying, but nobody is at risk if you stop. Since the tube is in civilisation (even at the extreme ends of the London Underground which are outside London, like Chesham, this is hardly wilderness, you can probably see a house from where your train stopped if there aren't trees in the way) we can just walk away.

https://commons.wikimedia.org/wiki/File:Chesham_Tube_Station...

> Linus was saying no, you carry on despite the error until you get to the next station

Depending on the error the consequences of attempting to "carry on" may be fatal and it's appropriate that the decision to attempt this rests with a human, and isn't just the normal function of a machine determined to get there regardless.

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

#273

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

I don't have any experience with this project, but I know a lot of panics in my Rust code look like this (you probably know this already, just setting up a question):

    fn foo() -> Option {
        // Oops, something went wrong and we don't have a T.
        None
    }

    fn bar() -> T {
        if let Some(t) = foo() {
            t
        } else {
            // This could've been an `unwrap`; just being explicit here
            panic!("oh no!");
        }
    }

A panic in this case is exactly like an exception in that the function that's failing doesn't need to come up with a return value. Unwinding happens instead of returning anything. But if I was writing `bar` and I was trying to follow a policy like "never unwind, always return something", I'd be in a real pickle, because the way the underlying `foo` function is designed, there aren't any T's sitting around for me to return. Should I conjure one out of thin air / uninitialized memory? What does the kernel do in situations like this? I guess the ideal solution is making `bar` return `Option` instead of `T`, but I don't imagine that's always possible?

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

#274

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

dcsommer wrote: post #264

layer8 wrote: post #233

Earlier quoted context omitted.

Linters like Splint [0] (predating Rust) can do that for C. I’m not saying that Rust’s built-in approach isn’t better, but please be careful about what exactly you claim. [0] http://splint.org/

Interesting that despite tools like Splint, 70% of high severity security vulns, including in well staffed projects like Chrome and Windows, are due to memory unsafety. The false negatives of security analysis tools are significant and are the very reason Rust got developed.

No, the reason Rust was developed (with regard to that aspect) was that the necessary static analysis is enforced by the compiler if it is built into the language, whereas otherwise (if not built in) it empirically doesn’t get a lot of adoption. There’s nothing Rust’s static analysis is doing that couldn’t be done with the same semantics using an external static analyzer and linter annotations.

The ideas of Rust weren’t new when Rust was developed. The actual integration into a new programming language beyond experimental status was, and the combination with ML-style functional programming.

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

#275

Post by flumpcakes » Sun, Oct 02, 2022, 4:55 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 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.

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

#276

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

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

I think you must have missed out on how Linux currently handles these situations. It does not silently move on past the error; it prints a stack trace and CPU state to the kernel log before moving on. So you have all of the information you'd get from a full kernel panic, plus the benefit of a system that may be able to keep running long enough to save that kernel log to disk.

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

#277

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

flohofwoe wrote: post #85

PragmaticPulp wrote: post #49

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…

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

When the CVEs appear in Rust, they use that as proof that their technology is better because they found those errors. Or, those were just unsafe and therefore not "real" Rust.

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

#278

Post by zozbot234 » Sun, Oct 02, 2022, 4:58 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 problem with #3 is not really about C vs. Rust, it's about modern optimizing compilers (including GCC). A compiler is allowed to assume that UB simply won't happen, so it makes no guarantees whatsoever about what happens if UB is ever hit. It's not "return a random value", it really is "all bets are off". There is no guarantee that you manage to "limp along" in any reasonable sense, let alone report the failure. That's what "panic and recover" mechanisms are for, and yes even the ? operator in Rust can be seen as such a mechanism.

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

#279

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

oconnor663 wrote: post #273

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…

I don't have any experience with this project, but I know a lot of panics in my Rust code look like this (you probably know this already, just setting up a question): fn foo () -> Option { // Oops, something went wrong and we don't have a T. None } fn bar () -> T { if let Some(t) = foo() { t } else { // This could've been an `unwrap`; just being explicit here panic!("oh no!"); } } A panic in this case is exactly like…

The harsh truth is that you need to think about every single case of failure, and decide what to do when things go south.

If you look at how POSIX does it, pretty much every single function has error codes, signaling everything from lost connections, to running out of memory, entropy or whatnot. Failures are hard to abstract away. Unless you have some real viable fallback to use, you're going to have to tell the user that something went wrong and leave it up to them to decide what the application can best do in this case.

So in your case, I would return Result, and encode the errors in that. Simply expose the problem to the caller.

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

#280

Post by lifthrasiir » Sun, Oct 02, 2022, 5:00 PM UTC

Yoric wrote: post #243

PragmaticPulp wrote: post #49

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…

It's really weird. I keep seeing claims that Rust users are insufferable and claim that Rust protects against everything. But, as someone who has started using Rust around 0.4, I have never seen these insufferable users. I imagine that they lurk on some communities?

I believe it boils down to hasty generalization, where you only recall (or are aware of) a few particularly noisy Rust users and take them as a representative of all Rust users. This kind of stereotype is unfortunately very hard to break.