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

391–400 of 542 posts

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

#391

Post by warinukraine »

mlindner wrote: post #326
warinukraine wrote: post #270

Hahaha I did notice there's a lot of magical thinking amongst the rust people. Prediction: in time the same will happen to "rust in the kernel" as happened to "c++ in the kernel": Linus will forbid it not because of some intrinsic problem with the language, but because the culture of the community prevented them from understanding the kernel rules.

The kernel is not a magical beast. Other kernels have already been written in Rust and work fine. The ideas of Rust are not "magical thinking", they're based on fundamental mathematical principals that are irrelevant to language or tool.

I didn't say that the ideas of rust are magical thinking. I said that the community falls into magical thinking a lot.

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

#392

Post by maxbond »

wtallis wrote: post #389
maxbond wrote: post #382

Earlier quoted context omitted.

A better analogy would be: Let's say if we have kernel A that contains a bug; we don't know when it will trigger or what it will do. We have another kernel, B, which has the same bug, but while we don't know when it will trigger, we know it will cause the device to halt. Which is the better kernel? I'd say B is nearly always the better choice, because halting is a known state it's almost always possible to recover fr…

> But if we were operating, say, a Mars rover, and shutting down meant we would never be able to boot again, then it'd be better take kernel A and attempt to recover from whatever state we find ourselves in. That's pretty exotic, however. That you view it as exotic is partly a lack of imagination on your part; with a little more effort it's possible to identify similar use cases that are much closer to home than Mars…

> [W]ith a little more effort it's possible to identify similar use cases that are much closer to home than Mars.

If you feel there are some that would add to this conversation, feel free to share them.

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

#393

Post by topspin »

mustache_kimono wrote: post #201
h2odragon wrote: post #149

Earlier quoted context omitted.

Threats? Slander? Do you feel that you're "speaking for a community" here?

Heck no! And I can't imagine anyone thinking I was? The threat is pretty clear? "If Rust people don't get this, we will have to part ways." This is an ultimatum? It's crazy girlfriend/boyfriend material? It's ridiculous after one contributor tries something that Linus thinks won't work in the kernel. Ridiculous . Just say no. The slander as well? "Rust’s community, in aggregate, have developed a reputation." And you…

> "If Rust people don't get this, we will have to part ways."

What are you quoting? I don't see this anywhere in the thread.

The nearest I see is:

    If you cannot get over the fact that the kernel may have other
    requirements that trump any language standards, we really can't work
    together.
A reasonable, politely delivered, statement directed to an individual as opposed to Rust. It was in response to this rather cringy bit of lecturing:

    No one is talking about absolute safety guarantees. I am talking about
    specific ones that Rust makes: these are well-documented and formally
    defined.
Rust has no formal language specification yet. It's still "an area of research," to paraphrase what is said when the question is asked. No defined memory model either; from the current Rust reference:

    Rust does not yet have a defined memory model. Various academics
    and industry professionals are working on various proposals, but
    for now, this is an under-defined place in the language.
One could argue (not me; I'm far too pragmatic for such things) that Linus is being exceptionally generous in entertaining Rust in its current state.

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

#394

Post by geraneum »

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…

> Rust is arguably less safe in that aspect than C, due to the general Rust practice of panicking upon unexpected conditions

For context, this is OP's sentence that I responded to in particular. Ensuring safety [1] is way less trivial than looking for a call to "panic" in the state machine. You can remove the calls to "panic" and this alone does not make your program safer than the equivalent C code. It just makes it more kernel friendly.

[1] not only memory safety

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

#395

Post by tialaramex »

gmueckl wrote: post #331
tialaramex wrote: post #272

Earlier quoted context omitted.

> The Rust way would be to panic, train stops in between stations and must be rebooted to continue. Which is safe. It's inconvenient, but it's safe. Failures of this sort do happen, electrical fires are probably the most extreme example. They're annoying, but nobody is at risk if you stop. Since the tube is in civilisation (even at the extreme ends of the London Underground which are outside London, like Chesham, thi…

Stopping a train in the tube between stations is not safe. You can't get off the train safely between stations. Most help can't reach a train stuck in a tube.

Trains can be, and sometimes are, evacuated in a tunnel. The front (and rear, these trains are symmetrical) can be opened, converting into steps for able-bodied passengers to walk down to the tunnel floor.

There's a video of passengers doing this for real in this 2016 news article:

https://www.bbc.co.uk/news/uk-england-london-36716256

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

#396

Post by mustache_kimono »

topspin wrote: post #393
mustache_kimono wrote: post #201

Earlier quoted context omitted.

Heck no! And I can't imagine anyone thinking I was? The threat is pretty clear? "If Rust people don't get this, we will have to part ways." This is an ultimatum? It's crazy girlfriend/boyfriend material? It's ridiculous after one contributor tries something that Linus thinks won't work in the kernel. Ridiculous . Just say no. The slander as well? "Rust’s community, in aggregate, have developed a reputation." And you…

> "If Rust people don't get this, we will have to part ways." What are you quoting? I don't see this anywhere in the thread. The nearest I see is: If you cannot get over the fact that the kernel may have other requirements that trump any language standards, we really can't work together. A reasonable, politely delivered, statement directed to an individual as opposed to Rust. It was in response to this rather cringy…

FWIW, I actually mostly agree with Linus.

I was paraphrasing. I didn't want to write a page length comment, and won't here, but there were a few more instances of similar ultimatums (like "Or, you know, if you can't deal with the rules that the kernel requires, then just don't do kernel programming.") And all are similarly ridiculous/dickish. Really no need for such dramatic convulsions, Linus, where Wedson was simply trying to explain the API expectations of the Rust language.

Re: the rest, I think you are conflating Rust's UB guarantees with a specified memory model.

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

#397

Post by swinglock »

alerighi wrote: post #141
swinglock wrote: post #121

Earlier quoted context omitted.

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…

> Aborting an operation is much better than incorrect results. Depends. Is a kernel panic better than something acting wrongly? I prefer my kernel not to panic, at the expense of some error somewhere that may or may not crash my system. If you look at the output of `dmesg` on any Linux system you often will see errors even in a perfectly working system. This is because programs of that size are by definition not perf…

> Depends. Is a kernel panic better than something acting wrongly? I prefer my kernel not to panic, at the expense of some error somewhere that may or may not crash my system.

That's a false dichotomy, you don't get to choose between definitely crashing or maybe crashing. That would be nice but it's not on the menu. Crashing is just the best case scenario, so if you can make your system stop instead of being incorrect, that's great.

> but we all disable them in production (assertions)

We don't all do that.

I concede that it depends on the use case. You might not care if you got a single user non-networked gaming console for example. A bug could even become a welcomed part of the experience there. I hope these cases are more rare than not though.

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

#398

Post by charcircuit »

secondcoming wrote: post #260
charcircuit wrote: post #107

Earlier quoted context omitted.

panic doesn't instantly crash the program. It prints out debug information first. You could have kernel panics work the same way.

Prints it out how? If the kernel has crashed how do you guarantee anything gets printed, either to the screen, tty, log file?

Print it to the cloud

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

#399

Post by charcircuit »

Someone1234 wrote: post #210
charcircuit wrote: post #107

Earlier quoted context omitted.

panic doesn't instantly crash the program. It prints out debug information first. You could have kernel panics work the same way.

And when Linux is running on your fridge, in your car, or on a headless VM then who is there to read out this "printed output." The great thing about "log and continue" is you can automate collection and fix the underlying bug (or know that the hardware is failing). Keep in mind that in a kernel panic no hardware is assumed to work, so assumptions like "just write to storage!" isn't an assumption you can make, you're…

>Keep in mind that in a kernel panic no hardware is assumed to work

So just change that assumption since for these edge cases that is an incorrect assumption.

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

#400

Post by rleigh »

WastingMyTime89 wrote: post #191
titzer wrote: post #148

Earlier quoted context omitted.

40 years of microkernels, of which I know Linus is aware of, beg to differ. Maybe Linus's extreme opposition to microkernels, ostensibly because they have historically a little lower performance--I dunno--but my comment should not be read as "yes, you must have a microkernel". There are cheaper fault isolation mechanisms than full-blown separate processes. Just having basic stack unwinding and failing a task would be…

Sorry it’s hard to take you seriously after that. Linux isn’t a microkernel. If you want to work on a microkernel, go work on Fuchsia. It’s interesting research but utterly irrelevant to the point at hand. Anyway, the microkernel discussion has been happening for three decades now. They haven’t historically had a little lower performance. They had garbage performance, to the point of being unsuitable in the 90s. Plen…

Others have mentioned QNX. There is also ThreadX, which is a "picokernel". Both are certified for use in safety-critical domains. There are other options as well. Segger do one, for example, and there's also SafeRTOS, and others.

"Performance" is a red herring. In a safety-critical system, what matters is the behaviour and the consistency. ThreadX provides timing guarantees which Linux can not, and all of the system threads are executed in strict priority order. It works extremely well, and the result is a system for which one can can understand the behaviour exactly, which is important for validating that it is functioning correctly. Simplicity equates to reliability. It doesn't matter if it's "slow" so long as it's consistently slow. If it meets the product requirements, then it's fine. And when you do the board design, you'll pick a part appropriate to the task at hand to meet the timing requirements.

Anyway, systems like ThreadX provide safety guarantees that Linux will never be able to. But the interface is not POSIX. And for dedicated applications that's OK. It's not a general-purpose OS, and that's OK too. There are good reasons not to use complex general-purpose kernels in safety-critical systems.

IEC 62304 and ISO 13485 are serious standards for serious applications, where faults can be life-critical. You wouldn't use Linux in this context. No matter how much we might like Linux, you wouldn't entrust your life to it, would you? Anyone who answered "yes" to that rhetorical question should not be trusted with writing safety-critical applications. Linux is too big and complex to fully understand and reason about, and as a result impossible to validate properly in good faith. You might use it in an ancillary system in a non-safety-critical context, but you wouldn't use it anywhere where safety really mattered. IEC 62304 is all about hazards and risks, and risk mitigation. You can't mitigate risks you can't fully reason about, and any given release of Linux has hundreds of silly bugs in it on top of very complex behaviours we can't fully understand either even if they are correct.

Post reply on HN