I'm not sure what he's trying to say here. Is he saying code that's run out of bounds of memory should continue on into la-la-land?
“Rust is safe” is not some kind of absolute guarantee of code safety
281–290 of 542 posts
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#282Earlier 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…
> 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 safety/correctness advantages of a statically-checked language like rust, or frankly even managed runtimes like .NET or Go. C code today lives in a very different world than it did even a decade ago.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#283As 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 don't have any experience with this project, but I know a lot of panics in my Rust code look like this (you probably know this already, just setting up a question): fn foo () -> Option { // Oops, something went wrong and we don't have a T. None } fn bar () -> T { if let Some(t) = foo() { t } else { // This could've been an `unwrap`; just being explicit here panic!("oh no!"); } } A panic in this case is exactly like…
Couple options:
1. Have a constraint on T that lets you return some sort of placeholder. For example, if you've got an array of u8, maybe every read past the end of the array returns 0.
fn bar() -> T {
if let Some(t) = foo() {
t
} else {
eprintln!("programmer error, foo() returned None!");
Default::default()
}
}
3. Return a `Result`, where `BarError` is a struct or enum describing possible error conditions.
#[non_exhaustive]
enum BarError {
FooIsNone,
}
fn bar() -> Result {
if let Some(t) = foo() {
Ok(t)
} else {
eprintln!("programmer error, foo() returned None!");
Err(BarError::FooIsNone)
}
}Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#284Earlier quoted context omitted.
I think, if the wording was exactly "Rust is safe" it is indeed too vague as there are many notions of safety, and annoyingly enough people do say this. But "Rust provides memory safety" is clear enough and doesn't need further quantification.
Official Rust materials are careful not to overpromise and to be clear on the extent of what is guaranteed and what isn't. The safety is always with an asterisk. Rust provides memory safety — provided that unsafe blocks, FFI, and other code running in the same process, and the OS itself, and the hardware doesn't misbehave. But if you accept that Python and Java can be called safe languages then Rust can be too. The o…
All this safety, as Linus points out, is safety for plain programs, but a complex of serious problem for the kernel. "Safe languages" are only safe up to a point and in context; Rust has clearly been designed to write safe applications, not safe kernels.
So if some enthusiasts are trying to use Rust at cross purposes for Linux they are likely to appear obnoxious and entitled, and it is perfectly right to challenge them to prove that they can make Rust suitable.
There's more high quality and polite preaching earlier in the thread, for example:
> Please just accept this, and really *internalize* it. Because this isn't actually just about allocators. Allocators may be one very common special case of this kind of issue, and they come up quite often as a result, but this whole "your code needs to *understand* the special restrictions that the kernel is under" is something that is quite fundamental in general.Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#285I’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's really weird. I keep seeing claims that Rust users are insufferable and claim that Rust protects against everything. But, as someone who has started using Rust around 0.4, I have never seen these insufferable users. I imagine that they lurk on some communities?
Okay, just to fact check this. I am a fan of Rust, but pretending there aren't these aggressive rust users is a bit putting your head in the sand.
Like any language that has very cool features, there are people that take that tool as not a tool but a religion.
You can even look in my comment history and see people arguing with me when I say I was a rust fan, but memory safety isn't a requirement in some areas of programming. One person made it there mission to convince me that can't possibly be the case and in (in my example of video games) that any memory bug crashes and game and will make users quit and leave.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#286Earlier 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)?
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.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#287Earlier quoted context omitted.
> it's definitely not what he wrote. I feel like we must have read two different articles. You sound crazy. Didn't read it your way at all. > Think of that "debugging tools give a huge warning" as being the equivalent of std::panic in standard rust. Yes, the kernel will continue (unless you have panic-on-warn set), because the kernel MUST continue in order for that "report to upstream" to have a chance of happening.…
He wrote: > In the kernel, "panic and stop" is not an option (it's actively worse than even the wrong answer, since it's really not debugable), so the kernel version of "panic" is "WARN_ON_ONCE()" and continue with the wrong answer. (edit, and): > Yes, the kernel will continue (unless you have panic-on-warn set), because the kernel MUST continue in order for that "report to upstream" to have a chance of happening. Di…
The error handler is the kernel. Whatever code runs to dump the panic somewhere must rely on some sort of device driver, which in turn must depend on other kernel subsystems and possibly other drivers to work.
There is an enormous variation in output targets for a panic on Linux: graphics hardware attached to PCIe (requires graphics driver and possibly support from PCIe bus master, I don't know), serial interface (USART driver), serial via USB (serial over USB driver, USB protocol stack, USB root hub driver, whatever bus that is attached to)... There is a very real chance that the error reporting ends up encountering the same issue (e.g. some inconsistent data on the kernel heap) while reporting it, Which would leave the developers with no information to work from if the kernel traps itself in an endless error handling loop.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#288Earlier quoted context omitted.
I didn't know the Azure CTO was the CTO was the C++ community. I'm sure the billions of lines of code written in C++ for the finance industry would love to have a word. The insufferable nature of the people isn't the advocating of safety. It's that Rust seems to have evolved a community of "X wouldn't have happened if Y was written in Rust!" and then walking away like they just transferred the one bit of knowledge ev…
> They occupy less than 1% of the programming community and act like they single-handedly are the only people who understand correctness. Maybe I’m too young (just past 30) but is it just me or is that some kind of attitude that emerged in the last 10-15 years? And I mean not only in programming, but in general. A small amount of people which is very vocal about something and start pushing everybody else to their thi…
>A small amount of people which is very vocal about something and start pushing everybody else to their thing while simultaneously shaming and/or making fun of those who either disagree or aren’t generally interested.
It's called manufacturing consent and it's all around us.
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#289> And the reality is that there are no absolute guarantees. Ever. The "Rust is safe" is not some kind of absolute guarantee of code safety. Never has been. Anybody who believes that should probably re-take their kindergarten year, and stop believing in the Easter bunny and Santa Claus. I thought that he had apologised and regretted being hostile in comments. Apparently not. Not that I have much of an issue with ranty…
> "WE'RE TRYING to guarantee the absence of undefined behaviour". That's an aim, not a claim they've either achieved it, or they can achieve it 100%
How is a "guarantee" not claiming something is 100% ?
Re: “Rust is safe” is not some kind of absolute guarantee of code safety
#290Earlier quoted context omitted.
> Linus goes nuclear. And while his reasoning is sound, his argumentation cycles between threats, bad-faith arguments, and just plain old yelling. In my opinion, in the software world, there is a large number of people who are very convinced of their own correctness. When they do something wrong or are simply mistaken, a gentle correction doesn't work. Linus is probably used to dealing with these people. I'm not sayi…
In light of this comment, one thing that makes me nervous about leading my own open-source project is that there might not be anyone who is willing to scream "WTF are you doing???" at me when I make a bad design decision.
Do you not have faith in yourself to receive feedback on your design if someone provided it in a less aggressive way?