“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

#511

Post by Suzuran » Mon, Oct 03, 2022, 1:33 PM UTC

ok_dad wrote: post #286

gmueckl wrote: post #251

Earlier quoted context omitted.

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)?

I worked in medical device quality control and so, yes, I know all about the FDA requirements for medical devices and ISO 13485. I can say, with certainty, that base Linux would not be allowed to run in a medical device in the USA. It's software of unknown provenance (SOUP) and would absolutely NOT be used as-is.

I am an American citizen and a former dialysis patient, now kidney transplant recipient. I have watched in-center dialysis machines reboot during treatment, show the old "Energy Star" BIOS logo, and then boot Linux...

Felt kinda bad until I thought about how well a "Linux literally killed me" headline would do on HN, but then I realized I wouldn't be able to post the article if I actually died. Such is life. Or death? One or the other.

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

#512

Post by kaba0 » Mon, Oct 03, 2022, 1:37 PM UTC

ajross wrote: post #458

jmillikin wrote: post #298

Earlier quoted context omitted.

Analysis for memory safety is really hard. For >40 years there's been entire sub-industries focused just on analysis of C/C++ memory safety and it's nowhere near a solved problem. That's why Rust has `unsafe`, it's so the programmer has a way to encode logic that they believe is safe but aren't yet able to prove. Analysis of panic-safety in Rust is comparatively easy. The set of standard library calls that can panic…

> That's why Rust has `unsafe`, it's so the programmer has a way to encode logic that they believe is safe but aren't yet able to prove. That's not the right way to characterize this. Rust has unsafe for code that is correct but that the compiler is unable to detect. Foreign memory access (or hardware MMIO) and cyclic data structures are the big ones, and those are well-specified, provable, verifiable regimes. They j…

I don’t really get your comment - are you agreeing or disagreeing with parent? Because you seemingly say the same thing.

And continuing on parent’s comment, rust can only make its memory guarantees by restricting the set of programmable programs, while C and the like’s static analysis has to work on the whole set which is simply an undecidable problem. As soon as unsafe is in the picture, it becomes undecidable as well in Rust, in general.

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

#513

Post by kaba0 » Mon, Oct 03, 2022, 1:39 PM UTC

ajross wrote: post #462

tialaramex wrote: post #350

Earlier quoted context omitted.

Rust makes choices which drastically simplify the analysis problem. The most obvious is mutable references. In Rust there can be either one mutable reference to an object or there may be any number of immutable references. So if we're thinking about this value here, V, and we're got an immutable reference &V so that we can examine V well... it's not changing, there are no mutable references to it by definition. The R…

That point would be stronger if Rust were showing up as faster than C compilers on this axis, and it isn't. In point of fact aliasing rules (which is what C calls the problem you're talking about) are very well travelled ground and the benefits and risks of -fno-strict-aliasing are well understood. Static analysis tools are in fact extremely good at this particular area of the problem. And of course at the level of e…

It’s not a problem, because compilers simply declare it as UB and don’t care about it. If you by accident did depend on that, your program will just get a nice, hard to debug bug.

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

#514

Post by voakbasda » Mon, Oct 03, 2022, 1:47 PM UTC

ok_dad wrote: post #369

voakbasda wrote: post #357

Earlier quoted context omitted.

That’s an odd thing to claim. I have worked on certified medical devices that run custom Linux distribution. Mind you, that experience also severely soured me on the quality of medical software systems, due to poor quality of the software that ran in that distribution. Linux itself was a golden god in comparison to the crap that was layered on top of it.

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.

These were not peripherals. We are talking devices that would be front line in an emergency room. Terrifying.

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

#515

Post by yencabulator » Mon, Oct 03, 2022, 2:02 PM UTC

notacoward wrote: post #510

yencabulator wrote: post #437

Earlier quoted context omitted.

What is better for a desktop user: 1) needing to reload a wifi driver to reinitialize hardware (with a tiny probability of memory corruption) OR choosing to reboot as soon as convenient (with a tiny probability of corrupting the latest saved files) 2) to lose unsaved files for sure and not even know what caused the crash

Why focus exclusively on the desktop, or over-generalize from it to other uses? What is appropriate for them is not necessarily so for the many millions of machines in server rooms and data centers. Also, you present a false dichotomy. "Lose unsaved files for sure" is not the case for many systems, and "not even know" is not necessarily the case. Logging during shutdown is a real thing, as is saving a crash dump for…

Yes, both need to remain options. Rust-in-kernel needs to be able to support both. That's like half of Linus's ranting there.

The other half is that kernel has a lot of rules of what is safe to be done where, and Rust has to be able to follow those rules, or not be used in those contexts. This is the GFP_ATOMIC part.

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

#516

Post by greyhair » Mon, Oct 03, 2022, 2:43 PM UTC

IshKebab wrote: post #496

chrsig wrote: post #78

Earlier quoted context omitted.

I mean, it's felt like anytime anyone mentions any code base not written in rust, someone pops in and points out that it's not safe , and should be rewritten in rust. I think it's all part of the language maturing process. Give it time, zealots will either move on to something new (and then harass the rust community for not meeting their new standard of excellence) or simmer down and get to work.

Well they're right. Most code written in C is horribly unsafe. Most code written in Rust is very safe. No code is guaranteed to be 100% safe - not even formally verified code. There's a clear safety spectrum, with C near the bottom and Rust near the top. It's tedious for people to keep saying "well it's not right at the top so we should just keep using C". I'm sure pro-seatbelt people were called "zealots" back in th…

> Most code written in C is horribly unsafe.

I think that is untrue. I worked at the Network Systems arm of Bell Labs for sixteen years, and we could demonstrate five-nines of uptime on complex systems written entirely in C.

C is a rough tool, I will grant you that, and Rust is a welcome addition to the toolkit, but saying that most code written in C is horribly unsafe, does not make it true.

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

#517

Post by __jem » Mon, Oct 03, 2022, 2:49 PM UTC

aspaceman wrote: post #216

titzer wrote: post #173

Earlier quoted context omitted.

Well, you've edited your reply a couple times, so it's a moving target, but: > * Panic and shut it all down. This prevents any reporting mechanism like a core dump. You cannot attach a normal debugger to the kernel. No one is really advocating that. Clearly you need to be able to write code that fails at a smaller granularity than the whole kernel . See my comment upthread about what I mean by that: dynamic errors fa…

Ease the snark space ranger. > dynamic errors fail smaller granularity tasks and handlers deal with tasks failing due to safety checks going bad. Yes and that's why Rust is bad here (but it doesn't have to be). Rust _forces_ you to stop the whole world when an error occurs. You cannot fail at a smaller granularity. You have to panic. Period. This is why it is being criticized here. It doesn't allow you any other gran…

> Rust _forces_ you to stop the whole world when an error occurs.

But... this isn't true??

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

#518

Post by paoda » Mon, Oct 03, 2022, 3:57 PM UTC

greyhair wrote: post #516

IshKebab wrote: post #496

Earlier quoted context omitted.

Well they're right. Most code written in C is horribly unsafe. Most code written in Rust is very safe. No code is guaranteed to be 100% safe - not even formally verified code. There's a clear safety spectrum, with C near the bottom and Rust near the top. It's tedious for people to keep saying "well it's not right at the top so we should just keep using C". I'm sure pro-seatbelt people were called "zealots" back in th…

> Most code written in C is horribly unsafe. I think that is untrue. I worked at the Network Systems arm of Bell Labs for sixteen years, and we could demonstrate five-nines of uptime on complex systems written entirely in C. C is a rough tool, I will grant you that, and Rust is a welcome addition to the toolkit, but saying that most code written in C is horribly unsafe, does not make it true.

Perhaps I misunderstand, but I don't imagine most individuals or companies writing production C code to be on the same "level of competency" as a research company as prestigious as Bell Labs.

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

#519

Post by ajross » Mon, Oct 03, 2022, 4:38 PM UTC

kaba0 wrote: post #512

ajross wrote: post #458

Earlier quoted context omitted.

> That's why Rust has `unsafe`, it's so the programmer has a way to encode logic that they believe is safe but aren't yet able to prove. That's not the right way to characterize this. Rust has unsafe for code that is correct but that the compiler is unable to detect. Foreign memory access (or hardware MMIO) and cyclic data structures are the big ones, and those are well-specified, provable, verifiable regimes. They j…

I don’t really get your comment - are you agreeing or disagreeing with parent? Because you seemingly say the same thing. And continuing on parent’s comment, rust can only make its memory guarantees by restricting the set of programmable programs, while C and the like’s static analysis has to work on the whole set which is simply an undecidable problem. As soon as unsafe is in the picture, it becomes undecidable as we…

The parent comment seemed to imply that using unsafe was a failing of the developer to prove to the compiler that the code is correct. And that's not right, unless you view thing like "doubly linked list" as incorrect code. Unsafe is for correct code that the compiler is unable to verify.

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

#520

Post by chrsig » Mon, Oct 03, 2022, 6:34 PM UTC

IshKebab wrote: post #496

chrsig wrote: post #78

Earlier quoted context omitted.

I mean, it's felt like anytime anyone mentions any code base not written in rust, someone pops in and points out that it's not safe , and should be rewritten in rust. I think it's all part of the language maturing process. Give it time, zealots will either move on to something new (and then harass the rust community for not meeting their new standard of excellence) or simmer down and get to work.

Well they're right. Most code written in C is horribly unsafe. Most code written in Rust is very safe. No code is guaranteed to be 100% safe - not even formally verified code. There's a clear safety spectrum, with C near the bottom and Rust near the top. It's tedious for people to keep saying "well it's not right at the top so we should just keep using C". I'm sure pro-seatbelt people were called "zealots" back in th…

The issue isn't correctness. The issue is annoyingness.

> I'm sure pro-seatbelt people were called "zealots" back in the day too.

Given that vehicles were grandfathered in, pro-seatbelt people were irrelevant to owners & drivers of said vehicle.

Just like some rust zealot asserting that some existing project with millions of lines of code should be rewritten in rust is irrelevant to the project maintainers.