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

331–340 of 542 posts

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

#331

Post by gmueckl »

tialaramex wrote: post #272
pwinnski wrote: post #237

Earlier quoted context omitted.

Linus' statement are applicable to the kernel only, and if we're using tube analogies, he was talking more about situations where the train is underway and something fails. The Rust way would be to panic, train stops in between stations and must be rebooted to continue. Linus was saying no, you carry on despite the error until you get to the next station. Much as the passengers in your story did.

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

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

#332

Post by jeffreygoesto »

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…

Well QNX is running on a gazillion of devices, even resource restricted ones, without problems. It can be slower but it does not have to always. That is gar from being a fantasy world.

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

#333

Post by avgcorrection »

layer8 wrote: post #316
avgcorrection wrote: post #307

Earlier quoted context omitted.

Memory safety is a well-defined term.

I agree, but that isn’t the term that was used here, and Rust proponents usually mean more than memory safety by “safe” (like e.g. absence of UB).

Going through that thread (a few posts back) it seems that “Rust is safe” (as seen in this submission title) was stated first by Torvalds. It wasn’t mentioned first by a “Rust aficianado”. So you would really have to ask Torvalds what he meant. But his mentioning of it (and this submission) obviously alludes to “safe” claims by the Rust project. Which has always been memory safety.

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

#334

Post by sidlls »

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…

The difference is these communities don’t have advocates spamming every technical thing they can find crapping on everyone else and proclaiming their favored language/tech to be indisputably superior in every case.

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

#335

Post by jeffreygoesto »

mike_hock wrote: post #246
titzer wrote: post #127

Earlier quoted context omitted.

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

It doesn't continue silently , it warns. More accurately, it does what you tell it to, which can also be a hard stop if you want to. It's up to you to choose the right failure strategy and monitor your system if you don't want to panic, and take appropriate measures and not just ignore the warning. It's not Linus who sounds ignorant here, it's the people applying user-space "best practices" to the kernel. If the kern…

I agree with your statements, but I wonder: who is warned typically? An end user via a log he neither reads nor understands? The chance that this will lead to the right measure is low, isn't it.

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

#336

Post by wtallis »

EdSchouten wrote: post #304
amluto wrote: post #300

Earlier quoted context omitted.

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.

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

That works for some systems: those for which "some NVRAM or something" evaluates to a real device usable for that purpose. Not all Linux systems provide such a device.

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

Userspace processes usually contain state that the user would also like to be persisted before rebooting. If my WiFi driver crashes, there's nothing helpful or safer about immediately bringing down the whole system when it's possible to keep running with everything but networking still functioning.

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

#337

Post by gmueckl »

jmillikin wrote: post #261
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)?

> including e.g. the monitor attached to the PC used for displaying > X-ray images Somewhat off-topic, but I used to work in a dental office. The monitors used for displaying X-rays were just normal monitors, bought from Amazon or Newegg or whatever big-box store had a clearance sale. Even the X-ray sensors themselves were (IIRC) not regulated devices, you could buy one right now on AliExpress if you wanted to.

That's not the case in the EU. I've worked for an equipment manufacturer for dental clinics. While the monitors were allowed to be off the shelf, the operator (dental clinic) is required to make sure that they work properly and display the image correctly - obey certain brightness and color resolution/calibration standards. Our display software had to refuse to work on an uncalibrated monitor.

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

#338

Post by layer8 »

yonixw wrote: post #328
layer8 wrote: post #324

Earlier quoted context omitted.

I’m not sure you understand Rice’s theorem correctly. It means that you can’t write an algorithm that takes an arbitrary program as input and tells you whether it fulfills a given nontrivial semantic property. But you can write an algorithm that can tell you for some subset of programs. So as a developer, if you restrict yourself to releasing programs for which the algorithm has halted and given you the desired answe…

But isn't every program we write today (Rust, C++, Python, JS, etc.) raise up to the level of an "arbitrary program"? How do you find those "some subset of programs" that will halt by said algorithm? The only sure way I can think of, is when you force your program to go through a more narrow non-turing algorithm. Like sending data through a network after Serialization. Where we could limit the De-Serialization proces…

For the first question, see the second paragraph I added in my previous comment.

Regarding the second question, in the general case you have to guess or think hard, and proceed by trial and error. You notice that the analyzer takes more time than you’re willing to wait, so you stop it and try to change your program in order to fix that problem.

We already have that situation today, because the Rust type system is turing-complete. Meaning, the Rust compiler may in principle need an infinite amount of time to type-check a program. Normally the types used in actual programs don’t trigger that situation (and the compiler also may first run out of memory).

By the way, even if Rust’s type system wasn’t turing-complete, the kind of type inference it uses takes exponential time, which in practice is almost the same as the possibility of non-halting cases, because you can’t afford to wait a hundred or more years for your program to finish compiling.

> But my point is, everyday program are "arbitrary program"

No, most programs we write are from a very limited subset of all possible programs. This is because we already reason in our heads about the validity and suitability of our programs.

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

#339

Post by oconnor663 »

acjohnson55 wrote: post #228

So much for Linus's time away to work on himself. It's disheartening to see how hard it is to change even when someone has the intention and resources to.

It's important to distinguish "better" from "perfect". That's how we get the motivation to make incremental progress every day.

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

#340

Post by dureuill »

layer8 wrote: post #259
Veliladon wrote: post #239

Earlier quoted context omitted.

In my case it wouldn't have raised an exception though, it would have just been UB. It's not like there's not exceptions in Rust though. The error handling is thorough to a fault when it's used. Unwrap is just a shortcut to say "I know there might be bad input, I don't want to handle it right now, just let me do it and I'll accept the panic."

By exceptions, I’m referring to languages with exceptions as a dedicated language construct with automatic stack unwinding, and preferably without UB (e.g. Java or C#). Rust doesn’t have exceptions in that sense.

But panics in rust are pretty much exceptions though?

The differences are they are actually meant to be used for exceptional situations ("assert violated => there's a bug in this program" or "out of memory, catastrophic runtime situation") and they are not typed (rather, the panic holds a type erased payload).

Other than that, it performs unwinding without UB, and is catchable[0]. I'm not seeing the technical difference?

[0]: https://doc.rust-lang.org/std/panic/fn.catch_unwind.html

Post reply on HN