“Rust is safe” is not some kind of absolute guarantee of code safety • Hacker News Board

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

#291

Post by oconnor663 » Sun, Oct 02, 2022, 5:07 PM UTC

wokwokwok wrote: post #75

throwawaybutwhy wrote: post #2

To put things in context, Linus is being reasonable and wise and well-mannered once again. Wouldn't mind reading a few juicy expletives, to be honest.

>>>>> For GFP_ATOMIC, we could use preempt_count except that it isn't always enabled. Conveniently, it is already separated out into its own config. How do people feel about removing CONFIG_PREEMPT_COUNT and having the count always enabled? >>>> No (Linus) >>> As you know, we're trying to guarantee the absence of undefined behaviour for code written in Rust. And the context is _really_ important, so important that le…

> Rust safety should be compile time. That’s the point…

Array bounds checks are one of the most important safety measures Rust takes, and those have to happen at runtime (if the optimizer can't prove they'll never fire). Similarly, locking types like `Mutex` of course do all their locking and unlocking at runtime, though they also use the type system to express the fact that they will do that.

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

#292

Post by maxbond » Sun, Oct 02, 2022, 5:08 PM UTC

3a2d29 wrote: post #285

Yoric wrote: post #243

Earlier quoted context omitted.

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

I, too, have not encountered these toxic Rust fanboys. I don't believe my head is in the sand. I do regularly see people degrading Rust and it's community, and so am convinced these toxic Rust fanboys are largely a myth based on uncharitable interpretations of otherwise reasonable statements. I think people often read "I advocate for the deprecation of all C/C++ codebases" into the statement "Rust is a 'safe' language, for a certain meaning of that term," but I don't think it's actually common to advocate for such a deprecation outside of security-critical applications.

I feel like it's a defensive reaction, that people feel like Rust is seeking to obviate arcane skills they've built over the course of their careers. Which I don't think is true, I think there will always be a need for such skills and that Rust has no mission to disrupt other language communities, but I can understand the reaction.

> You can even look in my comment history

Is this the thread you're referring to?

https://news.ycombinator.com/item?id=32878868

Because I genuinely don't see what you're talking about. No one seems to "make it their mission" and no one seems to be arguing for Rust in particular, as much as this category of languages.

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

#293

Post by gmueckl » Sun, Oct 02, 2022, 5:10 PM UTC

throw827474737 wrote: post #129

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?

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.

Yes. You could still hard reset after the error is reported if you wanted to. And if system availability matters, a hardware watchdog would handle the case where the error handling doesn't finish.

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

#294

Post by mlindner » Sun, Oct 02, 2022, 5:11 PM UTC

throw827474737 wrote: post #129

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?

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.

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

#295

Post by zozbot234 » Sun, Oct 02, 2022, 5:12 PM UTC

hegelstoleit wrote: post #215

pornel wrote: post #122

Earlier quoted context omitted.

Lack of a non-hacky no-panic guarantee is a pain. That would be like a no-segfault guarantee in C. But Rust's situation is still safer, because Rust can typically prevent more errors from ever becoming a run-time issue, e.g. you may not even need to use array indexing at all if you use iterators. You have a guarantee that references are never NULL, so you don't risk nullptr crash, etc. Rust panics are safer, because…

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.

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

#296

Post by mustache_kimono » Sun, Oct 02, 2022, 5:12 PM UTC

throw827474737 wrote: post #166

mustache_kimono wrote: post #115

Earlier quoted context omitted.

At least they don't go around slandering programming language communities. If we're going to be serious about who is being toxic, it's definitely Linus in this thread. Guy makes first mistake (by a very broad interpretation of "mistake". Perhaps "misunderstanding"?). Linus goes nuclear. And while his reasoning is sound, his argumentation cycles between threats, bad-faith arguments, and just plain old yelling. What so…

Guy makes mistake and even after that continues discussion though he already heard the agreed argument? I'm not understanding that if Linuxrusters want to do more their own thing and get rid of those rules and discussions they just fork off a real Linuxrustkernel and go off? The "political correct" toxicity comes from that group which continously wants to undermine long beforehand agreeds frontiers... (e.g. again thi…

> The "political correct" toxicity comes from that group which continously wants to undermine long beforehand agreeds frontiers

I have no idea what this actually refers to? "Panic is more safe"? Rust doesn't choose to panic on a failed memory allocation in the kernel, and never intended to. It was always TODO until it was implemented? Linus is using a userspace panic as an example here?

As to this thread's particular issue, the API for an allocation wasn't settled, and this is the discussion. I think the contributor was completely within his remit to say, "Heck, we could do this is a more memory safe way..." And Linus was completely right to say "Yeah, that's not how we do allocations here." The only problem is thinking being a dick is a good way to lead a community.

I think some fantasize about being able to be a dick in a FOSS project just like Linus (which feels like "if only I was a strong man dictator"), and I think that's an absurd desire. The Linux kernel is sui generis. In no other area of the world can anyone act this way, and be productive.

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

#297

Post by timeon » Sun, Oct 02, 2022, 5:13 PM UTC

Test0129 wrote: post #100

flohofwoe wrote: post #85

Earlier quoted context omitted.

> Rust is not an absolute guarantee of safety and doesn’t protect us from all the bugs. That's not exactly the vibe I'm getting from the typical Rust fanboys popping up whenever there's another CVE caused by the usage of C or C++ though ;) Rust does seem to attract the same sort of insufferable personalities that have been so typical for C++ in the past. Why that is, I have no idea.

I wouldn't say the Rust community parallels the C++ community in any way. The rust community is more like the insufferable Haskell/FP community who, despite producing very little measurable commercial value continue to look down on everyone else. Indeed, there's a lot of damage control going on in this thread walking back Rust's guarantees of safety despite that, up until this point, being Rust's only real selling po…

This seems to me more like wishful thinking. The post is barely talking about memory safety. You have confused combination of title and some post reacting to title of the post.

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

#298

Post by jmillikin » Sun, Oct 02, 2022, 5:13 PM UTC

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…

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 is finite, so if your tool just walks every call graph you can figure out whether panic is disproven or not.

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

#299

Post by flumpcakes » Sun, Oct 02, 2022, 5:13 PM UTC

hedora wrote: post #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 cr…

I can't take anything you say in good faith. Are you an AI trained on the Rust subreddit?

> According to the rust manual, when you make unsound libraries sound, common courtesy dictates you create a CVE for the old implementation.

I cannot find the words to describe how supercilious this is.

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

#300

Post by amluto » Sun, Oct 02, 2022, 5:17 PM UTC

EdSchouten wrote: post #138

jmillikin wrote: post #81

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…

The policy of ‘oopsing’ and limping on is, in my opinion, literally one of Linux’s worst features. It has bitten me in various cases: - Remember when Linux had that caused the kernel to partially crash and eat 100% CPU due to some bug in the leap second application code? That caused a >1MW spike in power usage at Hetzner at the time. That must have been >1GW globally. Many people didn’t notice it immediately, so it m…

As a kernel developer, I mostly disagree. Panicking hard is nice unless you are the user whose system rebooted without explanation or the developer trying to handle the bug report saying “my system rebooted and I have nothing more to say”.

Getting logs out is critical.