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

301–310 of 542 posts

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

#301

Post by lifthrasiir »

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…

While C/C++ has been made much safer by sanitizers, fuzzing and lints, they are:

- Only useful when actually being used, which is never the case. (Seriously, can we make at least ASAN the default?)

- Often costly to always turn them on (e.g. MSAN).

- Often requires restructuring or redesign to get the most out of them (especially fuzzing).

Rust's memory safety guarantee does not suffer from first two points, and the third point is largely amortized into the language learning cost.

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

#302

Post by a_humean »

LtWorf wrote: post #258
a_humean wrote: post #184

Earlier quoted context omitted.

You don't get to change the definition of a term used by another when it had a clear meaning in its use, and then make an arugment on the basis that the author meant y when they clearly meant x. That is just conflation.

I think the word "safety" existed before rust…

This has nothing to do with the common definition of "safety".Terms change their meaning based upon their use and context. The author has a clear use in mind - memory safety.

The rules of arugment existed long before the linux kernel. You don't get to change terms introduced within a arugment with a clear meaning because it helps you create a strawman. If you want to change the definition of a term mid arugment, you telegraph it. Once again, this is called conflation.

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

#303

Post by Vt71fcAqt7 »

a_humean wrote: post #184
LtWorf wrote: post #118

Earlier quoted context omitted.

Or, in other words, rust-safety should mean what safety means in every other context, or rust people need to come up with a different word.

You don't get to change the definition of a term used by another when it had a clear meaning in its use, and then make an arugment on the basis that the author meant y when they clearly meant x. That is just conflation.

>when it had a clear meaning in its use

Thats not the issue though. It's that "safe" means something is actualy safe. My house isn't safe if its on fire, even if the house is in a safe neighborhood. Linus' claim is that "rust people" sometimes themselves conflate memory saftey with general code saftey, simply because "safe" is in the name. So much so that they will at times sacrifice code quality to achieve this goal despite (a) memory saftey not being real saftey and (b) there is no way to guarantee memory saftey in the kernel anyway. What he is saying is that "rust people" (whatever that means) are at times trading off real saftey or real code maintenance/performance for "rust saftey."

>a compiler - or language infrastructure - that says "my rules are so ingrained that I cannot do that" is not one that is valid for kernel work.

And

>I think you are missing just how many things are "unsafe" in certain contexts and cannot be validated.

>This is not some kind of "a few special things".

>This is things like absolutely _anything_ that allocates memory, or takes a lock, or does a number of other things.

>Those things are simply not "safe" if you hold a spinlock, or if you are in a RCU read-locked region.

>And there is literally no way to check for it in certain configurations. None.

You can judge wheter he is correct but he never said rust's saftey implies absolute saftey, only that some rust users are treating it that way by sacrificing the code for it. If that's the case then it makes a lot of sense to start using a more sensible word like "guaranteed" instead of safe. I think part of what contibutes to this idea is that "unsafe" code is written with the keyword "unsafe" as if code written not that way is safe, and code written with "unsafe" is bad. That's not to say that "unsafe" actually implies any of that - all it means is that it's not guaranteed to be memory safe - but according to Linus it creates a certain mentality which is incongruent with the nature of kernel development. And the reason for that is that safe and unsafe are general english words with strong connotations such as:

>protected from or not exposed to danger or risk; not likely to be harmed or lost.

>uninjured; with no harm done.

And for unsafe:

>able or likely to cause harm, damage, or loss

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

#304

Post by EdSchouten »

amluto wrote: post #300
EdSchouten wrote: post #138

Earlier quoted context omitted.

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 .

One does not rule out the other. You could simply write crash info to some NVRAM or something, and then do a reboot. Then you can recover it during the next boot.

But there is no need to let userspace processes continue to run, which is exactly what Linux does.

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

#305

Post by aaaaaaaaaaab »

mynameisvlad wrote: post #144
aaaaaaaaaaab wrote: post #117

Earlier quoted context omitted.

>work environments It’s not a “work environment”. You can’t report Linus to HR. If you have a problem with him, you can fork the kernel and convince others to follow you. Then you’ll have a mailing list where you can ban Linus for his style. Good luck!

Yes because if he were at any company, he’d have been fired. Decades ago. Just because it’s not an official “work environment” per your definition does not mean it isn’t hostile or intolerable were it actually one. But actually countering that point is a lot harder, isn’t it?

>does not mean it isn’t hostile or intolerable were it actually one

It feels hostile and intolerable to you.

There are many people who find the risk-averse non-confrontational corpspeak intolerable.

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

#306

Post by yonixw »

layer8 wrote: post #136
geraneum wrote: post #128

Earlier quoted context omitted.

We cannot ensure that an arbitrary program halts by statically analyzing it. And it doesn’t have anything to do with the language of choice. https://en.m.wikipedia.org/wiki/Halting_problem

Proof assistants, which I expect to eventually merge with programming languages, can be used to restrict the set of programs you write to those where you can statically prove all properties you expect the program to hold. It’s not much different from what diligent programmers have always done in their head (with, of course, much more room for error). The fact that arbitrary programs are undecidable is a red herring h…

"Undecidable" Is way too close to your day2day program than you think: https://en.wikipedia.org/wiki/Rice%27s_theorem

I would like to learn otherwise, but even a React JS+HTML page is undecidable... its scope is limited by chrome V8 js engine (like a vm), but within that scope I don't think you can prove anything more. otherwise we could just make static analysis to check if it will leak passwords...

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

#307

Post by avgcorrection »

layer8 wrote: post #250
avgcorrection wrote: post #241

Earlier quoted context omitted.

And a perfect, bug-free ballistic rocket program is unsafe in the sense that it is efficient at causing damage. Rust’s “safety” has always meant what the Rust team meant by that term. There’s no gotcha to be found here except if you can find some way that Rust violates its own definition of the S-word. This submission is not really about safety. It’s a perfectly legitimate concern that Rust likes to panic and that pa…

That’s exactly my point. Rust’s definition of safety is a very specific one, and one has to be careful about what it actually implies in the context where Rust is employed. “Safety” isn’t a well-defined term for PL in general. “Soundness” is.

Memory safety is a well-defined term.

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

#308

Post by yonixw »

roywiggins wrote: post #190
geraneum wrote: post #128

Earlier quoted context omitted.

We cannot ensure that an arbitrary program halts by statically analyzing it. And it doesn’t have anything to do with the language of choice. https://en.m.wikipedia.org/wiki/Halting_problem

You can prove that a machine can't ever write "1" to the tape if you just look at the state machine and see that none of the rules write a 1 to the tape. Since no rules ever write 1, no possible execution could. Working out whether it will write 1 to the tape in general is undecidable, but in certain cases (you've just banned states that write 1) it's trivial. If all of the state transitions are valid (a transition t…

"Print 1" is trivial according to this: https://en.wikipedia.org/wiki/Rice%27s_theorem.

But day to day programs are not trivial... as for your example, just switch it with this code: `print(gcd(user_input--,137))`... now it's quite more hard to "just ban some final states"

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

#309

Post by mlindner »

sidlls wrote: post #68
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.

They probably are, in many cases. Rust’s community, in aggregate, have developed a reputation (earned, in my opinion). It’s too bad that the community don’t follow the leaders’ example in this regard. There are some quality, level-headed Rust advocates. They appear to be the minority.

Oh please. Stop smearing Wedson all over the map.

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

#310

Post by goodpoint »

ok_dad wrote: post #242
mike_hock wrote: post #202

Earlier quoted context omitted.

So instead of a power spike, we'd have had a major internet outage across the world, across the entire industry and beyond, probably, if everyone had panicked on oops. The blame really lies with people not monitoring their systems. As you said, you have the option to reboot on panic, but Linus is absolutely not wrong that this size does not fit all. What about a medical procedure that WILL kill the patient if interru…

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

> I know medical devices DO NOT use Linux

Absolutely false.

Post reply on HN