Live data from Hacker News

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

lkml.org

351–360 of 542 posts

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

#351

Earlier quoted context omitted.

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…

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

There have been various examples of WiFi driver bugs leading to security issues. Didn’t some Broadcom WiFi driver once have a bug in how it processed non-ASCII SSID names, allowing you to trigger remote code execution?

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

#352

Earlier quoted context omitted.

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.

And back then we had flamewars on comp.lang.c and comp.lang.c++, hence the .moderated versions of them.

I always been on the C++ side, when arguing on C vs C++ since 1993, already considered C a primitive option, coming from Turbo Pascal 6.0, and finding such a simplistic pseudo-macro assembler.

So yeah, in a sense the Rust community is similarly hyped as we were adopting Turbo Vision, CSet++, OWL, MFC, PowerPlant, Tools.h++, POET, and thinking C would slowly fade away, and we could just keep on using a language that while compatible with C, offered the necessary type system improvements for safer code.

But then the FOSS movement doubled down on C as means to write the GNU ecosystem, on the first editions of the GNU manifesto, and here we are.

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

#353

Earlier quoted context omitted.

I, too, have not encountered these toxic Rust fanboys. I don't believe my head is in the sand. I do regularly see people degrading Rust and it's community, and so am convinced these toxic Rust fanboys are largely a myth based on uncharitable interpretations of otherwise reasonable statements. I think people often read "I advocate for the deprecation of all C/C++ codebases" into the statement "Rust is a 'safe' languag…

I've seen both sides of this, as a Rust user and as a Go user. Rust users are generally friendly to one another, and to people who are interested in Rust. Hoever, some Rust users are toxic when talking to people outside the community or to people who disagree. That's why a lot of us (in the Rust community) don't notice it; we spend most of the time inside our own community talking to each other and being friendly to…

> Hoever, some Rust users are toxic when talking to people outside the community or to people who disagree.

I'm not even sure if this is the case. I have seen enough toxic Rust users, but at least in my experience they rarely overlap with who are active in the community. This suggests that they are experiencing typical newcomer syndrome, comparable to Haskell newcomers' urge to write a monad tutorial, and also explains that why a disproportional number of non-Rust users observe toxic Rust users---if you are a Rust user but don't preach about Rust everywhere, how can others tell if you are indeed a Rust user? :-)

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

#354
post #334

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.

If you don't think the Rust "community" receives the same sort of spam arguments from anti-Rust folks, then you're kidding yourself. And, yes, I completely understand that such arguments are super annoying. But the wrong response in my view is to answer with another stupid argument ("The Rust community is the problem.")

Was Wedson acting in an untoward way here that in some way exemplifies something significant about the Rust community? No, not really. So, yeah, I think your comment above is a pointless low blow, cheap shot, an excuse to act nasty about some super annoying Rust comment you probably read months ago. And it just sounds like whining to me.

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

#355

Sounds like the community should stop touting Rust as a “safe” language. It shouldn’t be the responsibility of every adopter to dig deep enough to find it’s actually not true.

https://doc.rust-lang.org/nomicon/what-unsafe-does.html

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

#356
post #259

Earlier quoted context omitted.

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

You’re probably right now that I’ve read up on it, I wasn’t previously aware of catch_unwind.

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

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

That’s an odd thing to claim. I have worked on certified medical devices that run custom Linux distribution.

Mind you, that experience also severely soured me on the quality of medical software systems, due to poor quality of the software that ran in that distribution. Linux itself was a golden god in comparison to the crap that was layered on top of it.

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

#358
post #356

Earlier quoted context omitted.

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

You’re probably right now that I’ve read up on it, I wasn’t previously aware of catch_unwind.

Glad to be of service. Note that the idiomatic error handling in rust is still Result based rather than panic/catch_unwind based.

Nevertheless a long living application like, e.g., a webserver will catch panics coming from its subtasks (e.g., its request handlers) via catch_unwind

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

#359
post #90

Earlier quoted context omitted.

From most users’ points of view, a lot of things the kernel does (e.g. a sound card driver) are non-critical so they’d prefer an error in that driver only killed that driver and not the whole kernel. Similarly, I’d be upset if a server rebooted because of a blip in its CD-ROM driver. And if you can just reload the module which errored, all the better. It would be cool if kernel Rust could implement a panic handler wh…

Wasn’t that the whole point of microkernels/minix vs monoliths? With drivers being in the kernel can you even restart the modules?

With Linux you can unload and reload modules (rmmod, insmod) so it’s a little un-monolithic in that sense.

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

#360
post #349
post #338

Earlier quoted context omitted.

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

> Regarding the second question, in the general case you have to guess or do trial and error. > You notice that the analyzer takes more time than you’re willing to wait, I see, thanks, didn't know about this feedback loop as I'm not a rust programmer. Still on my todo list to learn.

I don’t think it actually happens in Rust in practice, or only very rarely. I was more talking about the hypothetical case for any static analysis of nontrivial program properties as in Rice’s theorem.
Post reply on HN