Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lkml.org

Post reply on HN
Print view View original

441–450 of 542 posts

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

#441

Post by Jweb_Guru »

titzer wrote: post #225
aspaceman wrote: post #216

Earlier quoted context omitted.

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…

> You cannot fail at a smaller granularity. Rust needs to fix that then. So we agree on that.

What was said is not actually true of Rust.

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

#442

Post by sarlalian »

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.

Ok, that's good for a U.S. centric view. Do you know that every medical device manufactured in China, for use in China meets the same requirements? Same for India, Russia, etc. The U.S. isn't the world and I'd be surprised if Linux weren't in use in some critical systems around the world that would be shocking for U.S. experts on those types of systems.

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

#443

Post by Jweb_Guru »

yencabulator wrote: post #437
ChrisSD wrote: post #71

Earlier quoted context omitted.

What is better: continuing to "limp along" in some unknown corrupted state (aka undefined behaviour) or in a well defined (albeit invalid) state?

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.

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

#444

Post by yencabulator »

mlindner wrote: post #313
kweingar wrote: post #47

Classic Linus. From the closing paragraph, I feel like he’s under the impression that Rust-advocating contributors are putting Rust’s interests (e.g. “legitimizing it” by getting it in the kernel) above the kernel itself.

You're completely wrong here. There is no push to "legitimize" Rust by getting it into the kernel. A lot of people want to actively write drivers for Linux without having to use C to do it. Trying to tweak the kernel to make integration easier in a supposed non-harmful way doesn't harm anything.

Linus is specifically saying the proposed "tweak" is not desirable.

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

#445

Post by jmull »

coldtea wrote: post #223
jmull wrote: post #123

Earlier quoted context omitted.

> The point he makes is BS. "the reality is that there are no absolute guarantees. Ever" Yeah, DUH! You calling his point BS, but also strongly agreeing with it. I guess you find it too obvious. But while it's obvious to many, there seem to be many who do not understand it. Issues involving rust often get derailed to pointlessness when rust's safety guarantees are treated as an absolute.

> You calling his point BS, but also strongly agreeing with it. I'm only agreeing with the fact that there are no absolute guarantees. Not that his use of the fact in the point he makes has any relevance... If somebody had said "The earth is round, therefore we should not care about getting lost and GPS, because you always can always keep going and end up where you started on a sphere anyway", then I would have also…

The discussion is about what (if anything) the linux kernel should do to help satisfy the guarantees that rust wants to make.

Accepting the idea that rust guarantees aren't necessarily always good is needed to accept the idea that those guarantees might need to be relaxed, or at least don't necessarily justify linux kernel changes.

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

#446

Post by yencabulator »

detaro wrote: post #38
pca006132 wrote: post #29

Earlier quoted context omitted.

I guess when the kernel panics, there is nothing to write the core dump for you...

The kernel crash dump mechanism works by reserving some memory, which it boots a fresh copy of the kernel into on kernel panics, which then takes care of reading the old dead kernel from memory and saving the dump. Of course this working requires the fresh kernel to be able to get up and do that without itself crashing, so it can't capture every scenario. And it is bringing down the system completely, and there's lot…

The mechanism you describe is used/usable only in very specific scenarios.

For practically all non-virtualized Linux hosts out there, the kernel crash dump mechanism works by adding ASCII text to kmesg, which is then read by journald, processed a little, and appended to a file -- which just means submitted back to the kernel for writing, which means FS needs to work, disk I/O needs to work, and so on.

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

#447

Post by [deleted] »

zozbot234 wrote: post #295
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.

Panic in Rust need not equate to a literal kernel panic. It can call an oops handler, which might manage to keep the system operational depending on where the failure occurred.

[deleted]

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

#448

Post by layer8 »

avgcorrection wrote: post #439
layer8 wrote: post #434

Earlier quoted context omitted.

What I mean is that there is no universal definition of which properties are safety properties. In principle, you can define any property you can formally reason about as a safety property. Therefore, whenever you talk about safety, you first have to define which properties you mean by that. In the context of Rust, there are a number of safety properties that Rust guarantees (modulo unsafe , FFI UB, etc.), but that s…

> Therefore, whenever you talk about safety, you first have to define which properties you mean by that. Like “memory safety”?

For example. Rust has other safety properties beyond memory safety.

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

#449

Post by P5fRxh5kUvp2th »

ajross wrote: post #282
jmillikin wrote: post #130

Earlier quoted context omitted.

Rust doesn't have an official `#[never_panic]` annotation, but there's a variety of approaches folks use. Static analysis (Clippy) can get you pretty far. My favorite trick is to link a no_std binary with no panic handler, and see if it has a linker error. No linker error = no calls to panic handler = no panics. Note that Rust is easier to work with than C here, because although the C-like API isn't shy about panicki…

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

I've long been of the opinion that the rust community is missing the boat in a lot of respects.

Rust could do the external tooling better than any other language out there, but they're so focused on the _language_ preventing abuse that they've largely missed the boat.

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

#450

Post by UncleMeat »

layer8 wrote: post #434
UncleMeat wrote: post #373

Earlier quoted context omitted.

> “Safety” isn’t a well-defined term for PL in general. “Soundness” is. This is false. "Safety" and "Liveness" are terms used by the PL field to describe precise properties of programs and they have been used this way for like 50 years ( https://en.wikipedia.org/wiki/Safety_and_liveness_properties ). A "safety" property describes a guarantee that a program will never reach some form of unwanted state. A "liveness" pr…

What I mean is that there is no universal definition of which properties are safety properties. In principle, you can define any property you can formally reason about as a safety property. Therefore, whenever you talk about safety, you first have to define which properties you mean by that. In the context of Rust, there are a number of safety properties that Rust guarantees (modulo unsafe , FFI UB, etc.), but that s…

That's true for "soundness" too. Things aren't just "sound". They are sound with respect to something. So when you use "soundness" as a comparison against "safety", you'll have to understand how somebody could interpret your post in the way that I did.

Almost all discussion about Rust is in comparison to C and C++, by far the dominant languages for developing native applications. C and C++ are famously neither type-safe nor memory-safe and it becomes a pretty easy shorthand in discussions of Rust for "safety" to refer to these properties.

Post reply on HN