“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

#471

Post by ok_dad » Mon, Oct 03, 2022, 4:06 AM UTC

gmueckl wrote: post #406

ok_dad wrote: post #369

Earlier quoted context omitted.

I'd like to hear more about that, but I assume it's much like the other poster here that described a Linux system that is a peripheral device attached to the actual medical device that does the medical shit.

It is not a peripheral device if it runs the UI with all the main controls, is it?

No, do you have a concrete example of this strawman, though?

Edit: I should also add (probably earlier too) that all my examples are specific to the USA FDA process. I'm sure some other place might not have the same rules.

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

#472

Post by hegelstoleit » Mon, Oct 03, 2022, 4:11 AM UTC

lifthrasiir wrote: post #468

hegelstoleit wrote: post #463

Earlier quoted context omitted.

1. As far as i'm aware there's no way to reliably catch all panics. catch_unwind does not catch all panics. 2. The whole point is that consequences of a panic are worse than the consequences of memory corruption. That's how the kernel was designed. There was an explicit design decision not to kernel panic in every situation where a logic error occurs.

There are tons of edge cases with panics, e.g. panic can trigger a destructor that can panic itself, or unwinding may cross a language boundary which may not be well defined, but to my knowledge `catch_unwind` does catch all panics as long as unwinding reliably works. That disclaimer in the `catch_unwind` documentation only describes the `panic = abort` case. And I thought it was clear that kernel panic is different…

Obviously rust panic is not the same as a kernel panic. What you're taking for granted is that just because rust can catch a panic that it will. A simple overflow can cause a panic. When this happens, the panic might be caught before the kernel panics, but by then the program is probably already in an undefined state. It also might not be caught at all, and cause an actual kernel panic.

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

#473

Post by GauntletWizard » Mon, Oct 03, 2022, 4:12 AM UTC

gmueckl wrote: post #436

GauntletWizard wrote: post #428

Earlier quoted context omitted.

My guess is they had some heuristic based on EDIDs, which are incredibly easy to spoof. https://smile.amazon.com/EVanlak-Passthrough-Generrtion-Elim...

Yes, but why would you go to these lengths? The purpose of the whole mechanism is to prevent accidental misdiagnosis based on an incorrectly interpreted X-ray image. This isn't DRM, just a safeguard against incorrect use of equipment.

People are cheap and corrupt. The speed bump this presents is real, but minor, in the face of a couple medical shops looking to save $100/pop on a dozen monitors.

I hope it's rare, but I think a persistent nag window ("Your display isn't calibrated and may not be accurate") is probably a better answer than refusing to work altogether, because it will be clear about the source of the problem and less likely to get nailed down.

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

#474

Post by lifthrasiir » Mon, Oct 03, 2022, 4:47 AM UTC

hegelstoleit wrote: post #472

lifthrasiir wrote: post #468

Earlier quoted context omitted.

There are tons of edge cases with panics, e.g. panic can trigger a destructor that can panic itself, or unwinding may cross a language boundary which may not be well defined, but to my knowledge `catch_unwind` does catch all panics as long as unwinding reliably works. That disclaimer in the `catch_unwind` documentation only describes the `panic = abort` case. And I thought it was clear that kernel panic is different…

Obviously rust panic is not the same as a kernel panic. What you're taking for granted is that just because rust can catch a panic that it will. A simple overflow can cause a panic. When this happens, the panic might be caught before the kernel panics, but by then the program is probably already in an undefined state. It also might not be caught at all, and cause an actual kernel panic.

The program is in a defined but undesirable state, both when panic occurred in Rust and when a "simple" uncontrolled overflow happened in C (provided that the compiler is configured to not treat it as an UB, otherwise it'd be worse). And anyone doing Rust-C interop already has to be conscious about the language boundary, which happens to be a perfect place to catch Rust panics.

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

#475

Post by mslm » Mon, Oct 03, 2022, 5:17 AM UTC

pornel wrote: post #102

TillE wrote: post #74

Earlier quoted context omitted.

It's really common to see people say meaningless stuff like "Rust is a safe language" which is either deeply confused or deeply misleading. Rust provides certain guarantees of memory safety, which is great, but it's important to understand exactly what that means and not to oversell it.

It's an unproductive pedantry to expect every mention of the generalisation to be followed by a full disclaimer about exceptions and edge cases. People say "it's raining" without having to add "except under roofs".

Except everyone understands it's not raining under roofs. When someone says 'Rust is safe', they assume it infallible. It's been oversold.

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

#476

Post by yellowapple » Mon, Oct 03, 2022, 5:24 AM UTC

Gare wrote: post #271

pca006132 wrote: post #192

Earlier quoted context omitted.

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.

"Should" unfortunately ain't the same as "does". The Torvaldsian (for lack of a better word) attitude seems to be to assume that someone is indeed dumb enough to design a system wherein all safety measures are software-defined, and in such a situation the software in question probably shouldn't catastrophically fail on every last failed assertion.

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

#477

Post by chlorion » Mon, Oct 03, 2022, 5:26 AM UTC

atty wrote: post #25

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.

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.

The kernel can't panic and display an error message, but corrupting itself and deleting valuable data or allowing people to execute arbitrary code (possibly remotely) is okay?

I really have a hard time understanding how anyone could possibly think that's okay.

It sounds like the kernel's quality is so poor that UB is commonplace and even expected at this point. Pretty scary how many systems are relying on this huge pile of broken C code to hopefully only slightly corrupt itself and your system.

I'm not even sure how useful Rust in the kernel is going to be considering they want it to just ignore errors. You can't even have bounds checking on arrays because invalid accesses might be detected at runtime and cause an error, which is totally insane.

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

#478

Post by mslm » Mon, Oct 03, 2022, 5:28 AM UTC

rat9988 wrote: post #4

I am the only one who would have a hard time to collaborate on a project where the "collaborators" start their message with > You need to realize that > (a) reality trumps fantasy ?

Don't see what's wrong with it. He's leading one of the most high-profile and complex software system in the world with billions of users. If he was a softball all the time it'd be a mess. You have to be straightforward sometimes, or else people take too long to get the point.

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

#479

Post by acje » Mon, Oct 03, 2022, 5:29 AM 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…

I remember working on some telecom equipment in the 90ies. It had a x86/Unix feature rich distributed management system. In other words complicated and expected to fail. The solution was a “watch dog” circuit that the main CPU had to poll every 100ms or so. Three misses and the CPU would get hard rebooted by the watch dog.

This reminds me of two things. Good system design needs a hardware-software codesign. Oxide computers has identified this, but it was probably much more common before the 90ies than after. The second thing is that all things can fail so a strategy that only hardens the one component is fundamentally limited, even flawed. If the component must not fail you need redundancy and supervision. Joe Armstrong would be my source of quote if I needed to find one.

Both rust and Linux has some potential for improvement here, but the best answers may lie in their relation to the greater system, rather than within it self. I’m thinking of WASM and hardware codesign respectively.

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

#480

Post by John23832 » Mon, Oct 03, 2022, 5:29 AM UTC

notacoward wrote: post #386

mike_hock wrote: post #202

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? The proper answer to those is redundancy , not continuing in an unknown and quite likely harmful state.

Right. It's clear that many people have not heard of, or considered, Therac-25[1].

[1] https://en.wikipedia.org/wiki/Therac-25