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

211–220 of 542 posts

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

#211

Post by fritolaid »

titzer wrote: post #127
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 way to handle this is split up kernel work into fail-able tasks [1]. When a safety check (like array OOB) occurs, it unwinds the stack up to the start of the task, and the task fails. Linus sounds so ignorant in this comment. As if no one else thought of writing safety-critical systems in a language that had dynamic errors, and that dynamic errors are going to bring the whole system down or turn it into a brick.…

What if the task was invoked asynchronously (and maybe it keeps happening.) What does async stack unwinding entail in Rust? Is there a parent-child relationship between invoker and invokee? async scopes (https://rust-lang.github.io/wg-async/vision/roadmap/scopes.h...) ? I've not touched Rust at all.

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

#212

Post by throw827474737 »

mynameisvlad wrote: post #83
mid-kid wrote: post #65

Earlier quoted context omitted.

Just as many people have problems with this form of communication, many people find it hard to clearly express themselves in an environment where they're expected to put people's feelings above all else. What some might perceive as "hostile", others would simply call "honest". It's simply a matter of preference.

No, it’s not “simply a matter of preference” when it causes someone else to be in a hostile work environment. At that point, you’re affecting the lives of those around you. Sure, some people have medical conditions that might prevent them from seeing this, but even they put in an effort to be better. It stops being a “preference” when it actively hurts those around you. If you are an asshole, are known to be an assho…

> It’s shocking that advocating for safe and inclusive work environments is such a controversial topic. If he were any other person, his behavior would be quashed in a second.

It is not, because that is exactly the problem.. whats your view of safe and inclusive is to some hostile and exclusive.. and until people realize that this extreme creates similar well-behaved assholes: nevermind.

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

#213

Post by coldtea »

peoplefromibiza wrote: post #113
ukweld wrote: post #70

Earlier quoted context omitted.

Why are so many people criticizing Linus? This post strikes me as relatively moderate. Other software dictators do exactly the same, but in a more underhanded and bureaucratic manner, which is worse. Yet their disciples call them "benevolent". I can deal with Linus, but not with the latter. Linus strikes me as not being really serious or vindictive. It's just a colorful way of expressing himself.

because people of modern age have to destroy everything's good, to feel better about themselves, without having to actually be good.

Sort of how Linus pisses on Rust with a not-actually-good argument?

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

#214

Post by evouga »

swinglock wrote: post #121
blinkingled wrote: post #79

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

At least in user space, aborting an operation is much better than incorrect results. But the kernel being incorrect makes user space incorrect as well. First of all, making a problem both obvious and easier to solve is better. Nothing "only" about it - it's better. Better both for the programmers and for the users. For the programmer the benefit is obvious, for the user problems will simply be more rare, because the…

Saving a document is a great example: I would much rather that the kernel corrupt 20% of my unsaved work on a document (with a warning about the corruption), than crash and delete 100% of it.

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

#215

Post by hegelstoleit »

pornel wrote: post #122
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.

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.

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

#216

Post by aspaceman »

titzer wrote: post #173
aspaceman wrote: post #155

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

Well, you've edited your reply a couple times, so it's a moving target, but: > * Panic and shut it all down. This prevents any reporting mechanism like a core dump. You cannot attach a normal debugger to the kernel. No one is really advocating that. Clearly you need to be able to write code that fails at a smaller granularity than the whole kernel . See my comment upthread about what I mean by that: dynamic errors fa…

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 granularity. The top comment has some alternatives that still work in Rust.

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

#217

Post by armchairhacker »

what about a linter for Rust which highlights functions that may panic so you can avoid them? It seems like a fun project and useful feature

Unless I’m mistaken, in “safe” Rust, programs can still crash but only by calling “panic”, or other trivial cases (explicitly calling “exit” with a nonzero return value, calling into ffi code, etc)

Detecting functions which may “panic” and “exit” is very easy, significantly easier than detecting possible UB. Avoiding these functions (or providing a comment “no-panic guarantee” like “safety guarantee” for unsafe Rust) doesn’t seem very hard, since lots of panicking functions have a non-panicking variant.

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

#218

Post by lbhdc »

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.

I was under the impression that was the reason for the push.

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

#219

Post by MiguelX413 »

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…

What are those sysctls? It was worth my time to read Hacker News this morning.

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

#220

Post by LunaSea »

mynameisvlad wrote: post #198
LunaSea wrote: post #170

Earlier quoted context omitted.

That doesn't matter. It is his project and people are free ton join or start their own.

Of course it matters. There are many reasons why people might join one of his projects, many of which don’t involve him but instead the project itself. His presence might have stifled or grown involvement in those projects.

And that is completely fine.

People don't have a universal right to collaborate to this project, especially on their own terms.

In the same way, these projects will like you said, evolve in positive or negative ways with no God given right to exist and thrive.

Post reply on HN