Live data from Hacker News

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

lkml.org

311–320 of 542 posts

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

#311

Hmmm, the linked email is not providing a lot of context, so surely I'm missing something, but there's something I definitely don't understand: is there not a third option between stopping the whole kernel on an error or allowing an incorrect result? Maybe my misunderstanding comes from my ignorance of the kernel's architecture, but surely there's a way to segregate operations in logical fallible tasks, so that a fai…

>and in particular not a sensitive part like kernel error reporting

Things like "kernel error reporting" doesn't exist as discrete element. Sure, you might decide to stop everything and only dump log onto earlycon, but running with serial cable to every system that crashed would be rather annoying. For all kernel knows, the only way to get something to the outside world might be through USB Ethernet adapter and connection that is tunneled by userspace TUN device, at which point essentialy whole kernel must continue to run.

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

#312

Earlier quoted context omitted.

At least they don't go around slandering programming language communities. If we're going to be serious about who is being toxic, it's definitely Linus in this thread. Guy makes first mistake (by a very broad interpretation of "mistake". Perhaps "misunderstanding"?). Linus goes nuclear. And while his reasoning is sound, his argumentation cycles between threats, bad-faith arguments, and just plain old yelling. What so…

> At least they don't go around slandering programming language communities. Not so sure about this. I see a good amount of acrimony toward C, C++, Go, Zig, etc. from the Rust side.

> Zig

In this case it seems to be mutual. Even open hostility from some leading members of Zig community. Which is shame because these two languages could nicely coexist.

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

#313

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.

You're completely wrong here. There is no push to "legitimize" Rust by getting it into the kernel. A lot of people want to actively write drivers for Linux without having to use C to do it.

Trying to tweak the kernel to make integration easier in a supposed non-harmful way doesn't harm anything.

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

#314
post #64

I actually wondered with all the recent "Rust in the kernel" about culture clashes. I mean, most kernel developers aren't Rust programmers (and vice versa). Now we got a first glimpse at what happens. Still, I find it strange that it never seemed to come up in preparation to the first Rust merges. Were there any conflict resolution strategies in place (that I don't know about) or just "we flame it out on LKML"?

I think this is more "[modern] userspace vs kernel" than "Rust vs kernel". If you dig slightly below the surface in any major userspace codebase, it has abort paths everywhere . Every memory allocation might abort, every array index or dict lookup might throw an exception, which if uncaught will abort. Lock (or unlock) a mutex twice, abort. The Rust standard library inherited this philosophy in large and small ways.…

> they want to be able to panic() when something goes horribly wrong

I'm not sure where you are getting this from the thread? Linus is using a userspace panic as an example. That's not something that is actually happening in the kernel?

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

#315
post #50

Earlier quoted context omitted.

Then it's probably not the place for you, or people with thin skin that don't want to deal with that kind of tone/communication. If they lose out on talent because of it, that's their loss. Not every project has to be perfect and all-inclusive to the entire world of developers, and I'm okay with that.

It’s crazy to think that advocating for reasonable, non-toxic people to work with receives this kind response. Inclusivity and non-hostile work environments should not be considered “perfect” and “all-inclusive”. They should be basic . The default . The lowest bar possible .

So an "inclusive" and "non-toxic work environment" should put fantasy above reality? There's nothing inherently toxic in Linus' message; he's making a technical point about how kernel code should be designed, to deal effectively with the sometimes complex and challenging reality of low-level systems.

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

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

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

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

#317

Earlier quoted context omitted.

> Rust is not an absolute guarantee of safety and doesn’t protect us from all the bugs. That's not exactly the vibe I'm getting from the typical Rust fanboys popping up whenever there's another CVE caused by the usage of C or C++ though ;) Rust does seem to attract the same sort of insufferable personalities that have been so typical for C++ in the past. Why that is, I have no idea.

I wouldn't say the Rust community parallels the C++ community in any way. The rust community is more like the insufferable Haskell/FP community who, despite producing very little measurable commercial value continue to look down on everyone else. Indeed, there's a lot of damage control going on in this thread walking back Rust's guarantees of safety despite that, up until this point, being Rust's only real selling po…

I wonder if the Rust community now is similar to what the C++ community was like when C++ was as young as Rust is now. Any old-timers want to comment on this?

Edit to add: My guess is that the Rust community might still be worse because now we have widespread Internet access and social media.

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

#318
post #286

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.

Makes me wonder what they run their NAS software with. Or their internal web-hosting, or their networking devices, or any of the other devices they have littered about. I'd swear on the Bible that I've seen a dentist or two running KDE 3 before...

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

#319

This a naming/marketing issue. Because "safe" in the context of a programming language is provably wrong and thus will trigger adversary reactions. Rust is a hardened language, compared to C/C++. In the same way that Ada is hardened language, with different techniques, but the spirit is similar.

Rust isn't really hardened in the same way as Ada at all. They're almost perpendicular to each other.

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

#320

Earlier quoted context omitted.

Had the same topic often on MCUs: limp along to hopefully get the error out somehow, otherwise it won't be noticed if not with JTAG debugger attached (default in field). So I can understand where Linus comes from.

Limping along is what the salesman and the business people want as failures look bad. Engineers should want the immediate stop, because that's safer, especially in safety critical situations.

The kernel is not the whole system. The kernel needs to offer the "limping along" option so that the other parts of the system can implement whatever graceful failure method is appropriate for that system. There's no one size fits all solution for the kernel to pick.
Post reply on HN