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

431–440 of 542 posts

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

#431

Post by gmueckl »

alias_neo wrote: post #423
gmueckl wrote: post #337

Earlier quoted context omitted.

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.

Interesting, how does your software detect an uncalibrated monitor? Did it come with a calibration device which had to be used to scan the display output to check? I don't suppose monitors report calibration data back to display adapters do they?

I didn't work on that specific software team and it has been a long time since I worked there. But the software came with its custom calibration routine and I believe that the calibration result was stored with model and serial number information from the monitor EDID.

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

#432

Post by yencabulator »

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…

> When you attempt to save changes to your document, would you rather have the corruption of your document due to a bug fail with fanfare or succeed silently?

When your wifi driver crashes yet again, would you choose to discard all unsaved files open in your editor, just on the very unlikely possibility that they're corrupted now?

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

#433

Post by V_Terranova_Jr »

sidlls wrote: post #334
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…

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.

Extraordinary claims ought to be supported by extraordinary evidence. Those are some serious accusations you make.

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

#434

Post by layer8 »

UncleMeat wrote: post #373
layer8 wrote: post #250

Earlier quoted context omitted.

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.

> “Safety” isn’t a well-defined term for PL in general. “Soundness” is. This is false. "Safety" and "Liveness" are terms used by the PL field to describe precise properties of programs and they have been used this way for like 50 years ( https://en.wikipedia.org/wiki/Safety_and_liveness_properties ). A "safety" property describes a guarantee that a program will never reach some form of unwanted state. A "liveness" pr…

What I mean is that there is no universal definition of which properties are safety properties. In principle, you can define any property you can formally reason about as a safety property. Therefore, whenever you talk about safety, you first have to define which properties you mean by that.

In the context of Rust, there are a number of safety properties that Rust guarantees (modulo unsafe, FFI UB, etc.), but that set of safety properties is specific to Rust and not universal. For example, Java has a different set of safety properties, e.g. its memory model gives stronger guarantees than Rust’s.

Therefore, the meaning of “language X is safe” is entirely dependent on the specific language, and can only be understood by explicitly specifying its safety properties.

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

#435

Post by Gibbon1 »

jeffreygoesto wrote: post #335
mike_hock wrote: post #246

Earlier quoted context omitted.

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.

The couple of times I had to go digging into the kernel what the thing looks like to me is a very large bare metal piece of firmware. As someone who writes firmware that very last thing you ever want is it to hang or reset without reporting any diagnostics. Because you have no idea where the offending code is. I'll belabor the point for people that think a large program is a few thousand lands. With the kernel it's millions of lings of code mostly written by other people.

Small rant. ARM cortex processors overwrites the stack pointer on reset. That's very very very dumb because after the watchdog trips you have no idea what the code was doing. Which means you can't report what the code was doing when that happened.

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

#436

Post by gmueckl »

GauntletWizard wrote: post #428
alias_neo wrote: post #423

Earlier quoted context omitted.

Interesting, how does your software detect an uncalibrated monitor? Did it come with a calibration device which had to be used to scan the display output to check? I don't suppose monitors report calibration data back to display adapters do they?

My guess is they had some heuristic based on EDIDs, which are incredibly easy to spoof. https://smile.amazon.com/EVanlak-Passthrough-Generrtion-Elim...

Yes, but why would you go to these lengths? The purpose of the whole mechanism is to prevent accidental misdiagnosis based on an incorrectly interpreted X-ray image. This isn't DRM, just a safeguard against incorrect use of equipment.

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

#437

Post by yencabulator »

ChrisSD wrote: post #71
arinlen wrote: post #63

Earlier quoted context omitted.

> I know next to nothing about kernel programming, but I'm not sure here what Linus' objection to the comment he is responding to here is. You should read the email thread, as Linhas explains in clear terms. Take for instance Linus's insightful followup post: https://lkml.org/lkml/2022/9/19/1250

What is better: continuing to "limp along" in some unknown corrupted state (aka undefined behaviour) or in a well defined (albeit invalid) state?

What is better for a desktop user:

1) needing to reload a wifi driver to reinitialize hardware (with a tiny probability of memory corruption) OR choosing to reboot as soon as convenient (with a tiny probability of corrupting the latest saved files)

2) to lose unsaved files for sure and not even know what caused the crash

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

#438

Post by tomjakubowski »

layer8 wrote: post #154
dcsommer wrote: post #139

Earlier quoted context omitted.

> ... the general Rust practice of panicking upon unexpected conditions What makes you say this? From the sample I've seen, Rust programs are far more diligent about handling errors (not panicking: either returning error or handling it explicitly) than C or Go programs due to the nature of wrapped types like Option and Result . You can't escape handling the error, and panicking potential is very easy to see and lint…

I’m referring to the fact that ubiquitous functions like unwrap() panic if the programmer has made an error. Guarding against such panics is outside of the scope of Rust-the-language, and has to be handled through external means. There are linters for C as well.

> that ubiquitous functions like unwrap() panic if the programmer has made an error.

You're not wrong but you chose a hilarious example. Unwrap's entire purpose is to turn unhandled errors into panics!

Array indexing, arithmetic (with overflow-checks enabled), and slicing are examples where it's not so obvious there be panic dragons. Library code does sometimes panic in cases of truly unrecoverable errors also.

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

#439

Post by avgcorrection »

layer8 wrote: post #434
UncleMeat wrote: post #373

Earlier quoted context omitted.

> “Safety” isn’t a well-defined term for PL in general. “Soundness” is. This is false. "Safety" and "Liveness" are terms used by the PL field to describe precise properties of programs and they have been used this way for like 50 years ( https://en.wikipedia.org/wiki/Safety_and_liveness_properties ). A "safety" property describes a guarantee that a program will never reach some form of unwanted state. A "liveness" pr…

What I mean is that there is no universal definition of which properties are safety properties. In principle, you can define any property you can formally reason about as a safety property. Therefore, whenever you talk about safety, you first have to define which properties you mean by that. In the context of Rust, there are a number of safety properties that Rust guarantees (modulo unsafe , FFI UB, etc.), but that s…

> Therefore, whenever you talk about safety, you first have to define which properties you mean by that.

Like “memory safety”?

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

#440

Post by Jweb_Guru »

eric4smith wrote: post #48

“Rust is safe” is generally the same thing as saying “I like strongly typed languages”. None of that is going to save us from bad code. Some of the biggest systems that run the world are not written with either safe code nor strongly typed languages. Yes I would say strongly typed languages and memory safe languages help make coding easier and indeed save time and some bugs. But when you get past making the kinds of…

Unfortunately for this theory, about 70% of C and C++ CVEs are memory safety issues, not 5%.
Post reply on HN