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

461–470 of 542 posts

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

#461

Post by hegelstoleit »

layer8 wrote: post #233
hegelstoleit wrote: post #204

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/

Splint doesn't make C memory safe. What I meant is that it doesn't prevent the same problems that Rust does. Hence, you can add a linter to rust to prevent panics. You cannot add a linter to C to make it memory safe.

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

#462

Post by ajross »

tialaramex wrote: post #350
ajross wrote: post #282

Earlier quoted context omitted.

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

Rust makes choices which drastically simplify the analysis problem. The most obvious is mutable references. In Rust there can be either one mutable reference to an object or there may be any number of immutable references. So if we're thinking about this value here, V, and we're got an immutable reference &V so that we can examine V well... it's not changing, there are no mutable references to it by definition. The R…

That point would be stronger if Rust were showing up as faster than C compilers on this axis, and it isn't. In point of fact aliasing rules (which is what C calls the problem you're talking about) are very well travelled ground and the benefits and risks of -fno-strict-aliasing are well understood. Static analysis tools are in fact extremely good at this particular area of the problem. And of course at the level of emerging technologies, LTO makes this largely a non-issue because the compiler is able to see the aliasing opportunities at the level of global analysis. It doesn't need the programmer or the compiler to promise it an access is unaliased, it can just check and see.

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

#463

Post by hegelstoleit »

lifthrasiir wrote: post #248
hegelstoleit wrote: post #215

Earlier quoted context omitted.

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 corresponds to a potential logic bug. If you have a logic bug, you already risk its consequences even if the panic didn't happen. As long as panic can be caught (and in Rust, it's indeed the case) it is safer than the alternative.

1. As far as i'm aware there's no way to reliably catch all panics. catch_unwind does not catch all panics. 2. The whole point is that consequences of a panic are worse than the consequences of memory corruption. That's how the kernel was designed. There was an explicit design decision not to kernel panic in every situation where a logic error occurs.

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

#464

Post by hegelstoleit »

zozbot234 wrote: post #295
hegelstoleit wrote: post #215

Earlier quoted context omitted.

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.

As far as I'm aware there's no way to reliably catch all panics. catch_unwind does not catch all panics. Handlers don't stop the program from terminating abruptly.

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

#465

Post by yencabulator »

notacoward wrote: post #421
yencabulator wrote: post #415

Earlier quoted context omitted.

The leap second bug would have crashed all nodes of a redundant system, at the same time...

Perhaps. On the other hand, letting a medical device continue moving an actuator or dispensing a medication when it's known to be in a bad "never happen" state could also be fatal. Ditto for the "life support in space" example. Ditto for anything reliant on position, where the system suddenly realizes it has no idea whether its position is correct. Imagine that e.g. on a warship. Limiting responses to external inputs…

Picking medical devices and warships is also quite the cherry picking. Most Linuxes aren't like that. Critical embedded systems tend to have a hard realtime component, and if Linux is on the system it sits under e.g. seL4, or on a different CPU.

At the end of the day, what Linux does is what Linus wants out of it. He's stated, often, that halting the CPU at the exact moment something goes wrong is not the goal. If your goal is to do that, you might not be able to use Linux. If your goal is to put Rust in the Linux kernel, you might have to let go of your goal.

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

#466

Post by cplusplusfellow »

ok_dad wrote: post #286
gmueckl wrote: post #251

Earlier quoted context omitted.

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.

Surely we can “harden” Linux for this application?

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

#467

Post by jrochkind1 »

im3w1l wrote: post #152
jrochkind1 wrote: post #126

Earlier quoted context omitted.

> but Rust also has no built-in mechanism to statically determine “this code won’t ever panic”, My intuition says that's the Halting Problem, so not actually possible to implement perfectly? https://en.wikipedia.org/wiki/Halting_problem

If you are fine with saying that stuff like this code may panic (and many people are fine with just that), then it's perfectly doable if false { panic!() } Basically you'd prohibit any call to panic whether they may actually end up running or not.

Fair. From the responses, clearly i didn't know what I was talking about, fair enough!

But ok, uninformed me would have guessed checking for that would be pretty straightforward in statically typed Rust. Is that something people want? Why isn't there a built-in mechanism to do it?

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

#468

Post by lifthrasiir »

hegelstoleit wrote: post #463
lifthrasiir wrote: post #248

Earlier quoted context omitted.

Panic corresponds to a potential logic bug. If you have a logic bug, you already risk its consequences even if the panic didn't happen. As long as panic can be caught (and in Rust, it's indeed the case) it is safer than the alternative.

1. As far as i'm aware there's no way to reliably catch all panics. catch_unwind does not catch all panics. 2. The whole point is that consequences of a panic are worse than the consequences of memory corruption. That's how the kernel was designed. There was an explicit design decision not to kernel panic in every situation where a logic error occurs.

There are tons of edge cases with panics, e.g. panic can trigger a destructor that can panic itself, or unwinding may cross a language boundary which may not be well defined, but to my knowledge `catch_unwind` does catch all panics as long as unwinding reliably works. That disclaimer in the `catch_unwind` documentation only describes the `panic = abort` case.

And I thought it was clear that kernel panic is different from Rust panic, which you don't seem to distinguish. Rust panic doesn't need to cause a kernel panic because it can be caught earlier.

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

#469

Post by 3a2d29 »

maxbond wrote: post #367
3a2d29 wrote: post #363

Earlier quoted context omitted.

No I am not referring to that thread. I am referring to the thread further down where someone compares using a memory unsafe language to an illegal activity. If you need an example of the rust community being toxic, I give you https://github.com/actix/actix-web Look up the history and realize they bullied an open source project leader into leaving open source for good.

So this thread? https://news.ycombinator.com/item?id=32879558 I still don't understand the relevance, this neither appears toxic nor to be a discussion of Rust; this looks like they put forward an out-there idea and you didn't care for it, which just seems like a discussion about consumer protection laws. I also don't see the connection from Actix drama to the idea that people are exaggerating the capabilities of Rus…

I think the part where I have several negative votes on those comments, despite making points I think are valid, is what I don’t like.

My understanding is that negative votes is for things that don’t contribute to discussion, yet all my comments are in the negatives except when I mentioned I actually am using rust. Then suddenly the commenter stops talking about our discussion all together and starts to mention learning rust.

It’s frustrating because I like rust, but I can’t seem to criticize it in the slightest.

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

#470

Post by 3a2d29 »

maxbond wrote: post #367
3a2d29 wrote: post #363

Earlier quoted context omitted.

No I am not referring to that thread. I am referring to the thread further down where someone compares using a memory unsafe language to an illegal activity. If you need an example of the rust community being toxic, I give you https://github.com/actix/actix-web Look up the history and realize they bullied an open source project leader into leaving open source for good.

So this thread? https://news.ycombinator.com/item?id=32879558 I still don't understand the relevance, this neither appears toxic nor to be a discussion of Rust; this looks like they put forward an out-there idea and you didn't care for it, which just seems like a discussion about consumer protection laws. I also don't see the connection from Actix drama to the idea that people are exaggerating the capabilities of Rus…

Not to mention there was this whole issue: https://news.ycombinator.com/item?id=29501893

After saying everyone was empowered to use their tool, they tried to kick someone off the team for working for Palantir.

Regardless of politics, kinda unfair to make political statements using the rust accounts, then turn around and say other people can’t be part of rust because they work for a company who is political.

Post reply on HN