Live data from Hacker News

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

lkml.org

261–270 of 542 posts

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

#261
post #242

Earlier quoted context omitted.

> What about a medical procedure that WILL kill the patient if interrupted? What about life support in space? Hitting an assert in those kinds of systems is a very bad place to be, but an automatic halt is worse than at least giving the people involved a CHANCE to try and get to a state where it's safe to take the system offline and restart it. Kinda a strawman there. That's got to account for, what, 0.0001% of all u…

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

  > including e.g. the monitor attached to the PC used for displaying
  > X-ray images
Somewhat off-topic, but I used to work in a dental office. The monitors used for displaying X-rays were just normal monitors, bought from Amazon or Newegg or whatever big-box store had a clearance sale. Even the X-ray sensors themselves were (IIRC) not regulated devices, you could buy one right now on AliExpress if you wanted to.

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

#262
I find the Rust community to be hostile towards any inquisitive questions about their claims of "guaranteed memory safety". I've argued before that C is probably a safer language in practise for the Linux kernel than Rust because you would have to contort and write non-idiomatic Rust, using FFI, or deal with C data structures that will hamper/remove a lot of Rust's memory safe benefits. Rust is also harder to read than C - especially if you are trying to keep a mental model of the bitmap layout in your head and just dealing with low level code.

Of course I've had many negative comments from "Rustaceans", with their defence of their negativity being "we don't like it when someone comes into our community".

It is a shame because Rust is a pretty cool language, but at this current rate I don't really see it being "the" systems programming language de jure.

I think Zig is probably a much better fit for writing a Kernel in a safer language. Again, rust programmers pile on and tell me that "zig isn't memory safe". We can't make use of other languages that bring safety benefits without the dog pile of "you should use Rust it's safe". Apparently nothing is safe other than Rust.

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

#263

Earlier quoted context omitted.

> At least they don't go around slandering programming language communities. Not so sure about this. I see a good amount of acrimony toward C, C++, Go, Zig, etc. from the Rust side.

I think "acrimony" among languages (not language communities) is fine, like "you don't have an Option type?" or "you don't guarantee I won't have a use after free?". I think saying the "The Go/Rust/Zig community is uniquely toxic" crosses a line. And, to be very clear, if Rust people do it, I think it's awful as well.

It’s not unique to Rust’s community at all. I think they have relatively more visibility in places like HN, currently.

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

#264
post #233

Earlier quoted context omitted.

Linters can catch panics, linters for C won't catch memory issues which is what rust prevents.

Linters like Splint [0] (predating Rust) can do that for C. I’m not saying that Rust’s built-in approach isn’t better, but please be careful about what exactly you claim. [0] http://splint.org/

Interesting that despite tools like Splint, 70% of high severity security vulns, including in well staffed projects like Chrome and Windows, are due to memory unsafety. The false negatives of security analysis tools are significant and are the very reason Rust got developed.

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

#265

> Even "safe" rust code in user space will do things like panic when things go wrong (overflows, allocation failures, etc). If you don't realize that that is NOT some kind of true safely[sic], I don't know what to say. > Not completing the operation at all, is not really any better than getting the wrong answer, it's only more debuggable. What Linus is saying is 100% right of course - he is trying to set the expectat…

Great explanation. I am not an expert on this, so your comment helped me understand. It sounds like Linus is just being a good kernel maintainer here, and clarifying a misunderstood technical term - safety.

It's not a condemnation of rust, but rather a guidepost that, if followed, will actually benefit rust developers.

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

#266

As usual HN comments react to the headline, without reading the content. A lot of modern userspace code, including Rust code in the standard library, thinks that invariant failures (AKA "programmer errors") should cause some sort of assertion failure or crash (Rust or Go `panic`, C/C++ `assert`, etc). In the kernel, claims Linus, failing loudly is worse than trying to keep going because failing would also kill the fa…

I might be missing something here. So I understand panic! will essentially crash the kernel, that makes sense to me as a problem.

But wouldn't reading outside an array bounds also possibly do that? It coudl seg fault which is essentially the same thing.

Is it that reading out of bounds on an array isn't guaranteed to crash everything while a panic always will?

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

#267
I normally enjoy Linus rants, but he needs to RTFM.

In rust, safe code is code that does not have the unsafe keyword.

If all the unsafe code is sound, then you (provably) get high level guarantees about memory safety, etc.

The rust people are complaining that some of the unsafe RCU is unsound. They have a valid point. According to the rust manual, when you make unsound libraries sound, common courtesy dictates you create a CVE for the old implementation.

This is all in the rust book; it's pretty close to "hello world".

Anyway, the rust crowd is definitely right here. It would be better if the rust RCU bindings were sound.

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

#268
post #209
post #199

Earlier quoted context omitted.

One has to be careful about words. When Rust (or Linux) is used in (say) a vehicle or in a nuclear power plant, panicking certainly has immediate safety implications.

But it can still be safer - e.g. a panic can trigger an emergency stop instead of silently overwriting the "go full throttle" variable.

Yes, or jumping to the "emergency stop" routine can instead trigger "go full throttle" because the jump address has been corrupted.

Or in an actual vehicle, the "emergency stop" (if that means just stomping on the brakes) can flip the car and kill its passengers.

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

#270
Hahaha I did notice there's a lot of magical thinking amongst the rust people.

Prediction: in time the same will happen to "rust in the kernel" as happened to "c++ in the kernel": Linus will forbid it not because of some intrinsic problem with the language, but because the culture of the community prevented them from understanding the kernel rules.

Post reply on HN