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

341–350 of 542 posts

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

#341

Post by pdimitar »

jmillikin wrote: post #130
layer8 wrote: post #99

Earlier quoted context omitted.

Please correct me if I’m wrong, but Rust also has no built-in mechanism to statically determine “this code won’t ever panic”, and thus with regards to Linux kernel requirements isn’t safer in that aspect than C. To the contrary, Rust is arguably less safe in that aspect than C, due to the general Rust practice of panicking upon unexpected conditions.

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…

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

Oh? How do you do that? Do you have a written guide handy? Very curious about this.

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

#344

Post by pjmlp »

WastingMyTime89 wrote: post #191
titzer wrote: post #148

Earlier quoted context omitted.

40 years of microkernels, of which I know Linus is aware of, beg to differ. Maybe Linus's extreme opposition to microkernels, ostensibly because they have historically a little lower performance--I dunno--but my comment should not be read as "yes, you must have a microkernel". There are cheaper fault isolation mechanisms than full-blown separate processes. Just having basic stack unwinding and failing a task would be…

Sorry it’s hard to take you seriously after that. Linux isn’t a microkernel. If you want to work on a microkernel, go work on Fuchsia. It’s interesting research but utterly irrelevant to the point at hand. Anyway, the microkernel discussion has been happening for three decades now. They haven’t historically had a little lower performance. They had garbage performance, to the point of being unsuitable in the 90s. Plen…

QNX and INTEGRITY customers will be to differ.

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

#345

Post by gmueckl »

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.

Then you should know that the use of SOUP is not so clear cut. It depends on the class of device and more specifically, on the part of the device that the software is used on. I know medical devices running SOUP operating systems like Linux. They went to some length to show that the parts running Linux and the critical functions of the device were sufficiently independent. This isolation is specifically allowed by the standards you quote.

It's even worse on things like car dashboards: some warning lights on dashboards need to be ASIL-D conformant, which is quite strict. However, developing the whole dashboard software stack to that standard is too expensive. So the common solution these days is to have a safe, ASIL-D compliant compositor and a small renderer for the warning lights section of the display while the rendering for all the flashy graphics runs in an isolated VM on standard software with lower safety requirements. It's all done on the same CPU and GPU.

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

#346

Post by oconnor663 »

Pulcinella wrote: post #9

Not all that familiar with the specifics of Rust, but I assume it’s “safety” is somewhat similar to Swift’s “safety,” so type safety and memory safety, which does not mean no crashes, just that you will e.g. crash on an array OOB error rather than start writing or reading to random bits of memory.

You've got the right idea. The Rustonomicon gives a list of approximately everything that Rust considers unsound/UB (https://doc.rust-lang.org/nomicon/what-unsafe-does.html). The most common examples are:

- use after free

- breaking the aliasing rules

- causing a "data race" (e.g. writing to the same value from multiple threads without a lock)

- producing an invalid value (like a bool that's not 0 or 1)

There's some other technical stuff like "calling a foreign function with the wrong ABI", but those four above capture most of what safe Rust wants to guarantee that you never do. I contrast, the same page provides an interesting list of things that Rust doesn't consider UB and that you can do in safe code, for example:

- deadlocks and other race conditions that aren't data races

- leak memory

- overflow an integer

- abort the whole process

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

#347

Post by layer8 »

avgcorrection wrote: post #333
layer8 wrote: post #316

Earlier quoted context omitted.

I agree, but that isn’t the term that was used here, and Rust proponents usually mean more than memory safety by “safe” (like e.g. absence of UB).

Going through that thread (a few posts back) it seems that “Rust is safe” (as seen in this submission title) was stated first by Torvalds. It wasn’t mentioned first by a “Rust aficianado”. So you would really have to ask Torvalds what he meant. But his mentioning of it (and this submission) obviously alludes to “safe” claims by the Rust project. Which has always been memory safety.

I disagree that “safe” as used by the Rust community is always restricted to memory safety, see my parent comment.

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

#348

Post by pjmlp »

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 is the same argument that C folks used against Modula derived languages, Object Pascal and Ada.

If there isn't 100% safety then why bother, it is the usual argument for the last 40 years.

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

#349

Post by yonixw »

layer8 wrote: post #338
yonixw wrote: post #328

Earlier quoted context omitted.

But isn't every program we write today (Rust, C++, Python, JS, etc.) raise up to the level of an "arbitrary program"? How do you find those "some subset of programs" that will halt by said algorithm? The only sure way I can think of, is when you force your program to go through a more narrow non-turing algorithm. Like sending data through a network after Serialization. Where we could limit the De-Serialization proces…

For the first question, see the second paragraph I added in my previous comment. Regarding the second question, in the general case you have to guess or think hard, and proceed by trial and error. You notice that the analyzer takes more time than you’re willing to wait, so you stop it and try to change your program in order to fix that problem. We already have that situation today, because the Rust type system is tur…

> Regarding the second question, in the general case you have to guess or do trial and error.

> You notice that the analyzer takes more time than you’re willing to wait,

I see, thanks, didn't know about this feedback loop as I'm not a rust programmer. Still on my todo list to learn.

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

#350

Post by tialaramex »

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…

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 Rust language won't let us have &mut V the mutable reference at the same time &V exists and so it needn't ever account for that possibility†.

In C and C++ they break this rule all the time. It's really convenient, and it's not forbidden in C or C++ so why not. Well, now the analysis you wanted to do is incredibly difficult, so good luck with that.

† This also has drastic implications for an optimiser. Rust's optimiser can often trivially conclude that a= f(b); can't change b where a C or C++ optimiser is obliged to admit that actually it's not sure, we need to emit slower code in case b is just an alias for a.

Post reply on HN