Live data from Hacker News

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

lkml.org

451–460 of 542 posts

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

#451

Earlier quoted context omitted.

Had the same topic often on MCUs: limp along to hopefully get the error out somehow, otherwise it won't be noticed if not with JTAG debugger attached (default in field). So I can understand where Linus comes from.

Limping along is what the salesman and the business people want as failures look bad. Engineers should want the immediate stop, because that's safer, especially in safety critical situations.

You sound like you code websites or something.

Real engineers, like say the people who code the machines that fly in mars, don't want "oops that's unexpected, ruin the entire mission because that's safer". Same for the Linux kernel.

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

#452

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

The latter, because the "tiny probability of memory corruption" can easily become a CVE.

We have a term for this.

FUD

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

#453

Earlier quoted context omitted.

Unreasonable people build things. Reasonable people run meetings.

Reasonable people also build things. Unreasonable people also build things alone where everyone else doesn’t have to deal with them. The world is hardly as black and white as you make it seem.

Can you imagine seriously making the claim that Linus built Linux alone.

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

#454

Earlier quoted context omitted.

Reasonable people also build things. Unreasonable people also build things alone where everyone else doesn’t have to deal with them. The world is hardly as black and white as you make it seem.

Can you imagine seriously making the claim that Linus built Linux alone.

Who made that claim? I certainly didn’t.

Just as the parent comment generalized about the two kinds of people out there, I added other examples of generalizations about people. But that’s all they are, generalizations. Not specific examples.

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

#455

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

it might be in a virtualized/development env. but otherwise that's why all those defensive coding practices are recommended in low-level code. to deal with this.

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

#456

Earlier quoted context omitted.

The latter, because the "tiny probability of memory corruption" can easily become a CVE.

We have a term for this. FUD

Linux has numerous CVEs, and a large percentage stem from memory corruption. That's not FUD, I'm afraid.

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

#457

“Rust is safe” is generally the same thing as saying “I like strongly typed languages”. None of that is going to save us from bad code. Some of the biggest systems that run the world are not written with either safe code nor strongly typed languages. Yes I would say strongly typed languages and memory safe languages help make coding easier and indeed save time and some bugs. But when you get past making the kinds of…

Unfortunately for this theory, about 70% of C and C++ CVEs are memory safety issues, not 5%.

> 95% of bugs are logic errors

> 70% of CVEs are memory errors

No contradiction here.

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

#458
post #282

Earlier quoted context omitted.

> Static analysis (Clippy) can get you pretty far. What's funny about this is that (while it's true!) it's exactly the argument that Rustaceans tend to reject out of hand when the subject is hardening C code with analysis tools (or instrumentation gadgets like ASAN/MSAN/fuzzing, which get a lot of the same bile). In fact when used well, my feeling is that extra-language tooling has largely eliminated the practical sa…

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 just don't fit within the borrow checker's world view.

Which is something I think a lot of Rust folks tend to gloss over: even at it's best, most maximalist interpretation, Rust can only verify "correctness" along axes it understands, and those aren't really that big a part of the problem area in practice.

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

#459

So much for Linus's time away to work on himself. It's disheartening to see how hard it is to change even when someone has the intention and resources to.

It's important to distinguish "better" from "perfect". That's how we get the motivation to make incremental progress every day.

I would say this demonstrates inadequate progress.

As a manager, if I had a report who exhibited this level of verbal aggression, we would have a talk, and if it happened again, we'd be going through HR. It's not acceptable, regardless of technical merit.

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

#460

Earlier quoted context omitted.

Anyone who has to interact with him pretty much.

They can very much avoid it. They chose to. Who's to blame here?

Easy. Linus for being insufferable.
Post reply on HN