Live data from Hacker News

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

lkml.org

361–370 of 542 posts

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

#361

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

> Things like "kernel error reporting" doesn't exist as discrete element.

I'm not familiar with kernel development in general or Linux in particular. I would have expected there to be an error reporting subsystem, so that if a given subsystem fails the failure is reported to the error reporting subsystem (which hopefully exposes a more modern interface than serial cable), but this might be naive on my part.

> 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

Again I'm missing context on this discussion. For all I know this could be an error originating with a driver, since rust support for Linux is for driver development now. It would make sense to me that an error in the GPU driver doesn't prevent the ethernet driver to report the bug

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

#362

Earlier quoted context omitted.

The policy of ‘oopsing’ and limping on is, in my opinion, literally one of Linux’s worst features. It has bitten me in various cases: - Remember when Linux had that caused the kernel to partially crash and eat 100% CPU due to some bug in the leap second application code? That caused a >1MW spike in power usage at Hetzner at the time. That must have been >1GW globally. Many people didn’t notice it immediately, so it m…

What are those sysctls? It was worth my time to read Hacker News this morning.

Maybe these? https://www.cyberciti.biz/tips/reboot-or-halt-linux-system-i...

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

#363
post #285

Earlier quoted context omitted.

Okay, just to fact check this. I am a fan of Rust, but pretending there aren't these aggressive rust users is a bit putting your head in the sand. Like any language that has very cool features, there are people that take that tool as not a tool but a religion. You can even look in my comment history and see people arguing with me when I say I was a rust fan, but memory safety isn't a requirement in some areas of prog…

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…

No I am not referring to that thread. I am referring to the thread further down where someone compares using a memory unsafe language to an illegal activity.

If you need an example of the rust community being toxic, I give you https://github.com/actix/actix-web

Look up the history and realize they bullied an open source project leader into leaving open source for good.

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

#364

Earlier quoted context omitted.

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

We're not talking about bugs in general, we're talking about bugs whose manifestation is caught by error checking already in the code. For device drivers, those situations can often be handled safely by simply disabling the device in question while leaving the rest of the OS running. I doubt the Broadcom bug you're thinking of triggered a WARN_ON() in the code path allowing for a remote code execution. (Also, the highest-profile Broadcom WiFi remote code execution bug I'm aware of was a bug in the WiFi chip's closed-source firmware, which doesn't even run on the same processor as the host Linux OS.)

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

#365
post #286

Earlier quoted context omitted.

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.

[deleted]

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

#366
post #286

Earlier quoted context omitted.

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.

Then you should know that the use of SOUP is not so clear cut. It depends on the class of device and more specifically, on the part of the device that the software is used on. I know medical devices running SOUP operating systems like Linux. They went to some length to show that the parts running Linux and the critical functions of the device were sufficiently independent. This isolation is specifically allowed by th…

> They went to some length to show that the parts running Linux and the critical functions of the device were sufficiently independent.

Let's not be too pedantic. You, as an experienced medical device engineer, probably knew what I meant was that they would never use Linux in the critical parts of a medical device as the OP had originally argued. Any device would definitely do all of it's functionality without the part with Linux on it.

The OP was still a major strawman, regardless of my arguments, because the Linux kernel will never be in the critical path of a medical device without a TON of work to harden it from errors and such. Just the fact that Linus' stance is as said would mean that it's not an appropriate kernel for a medical device, because they should always fail with an error and stop under unknown conditions rather than just doing some random crap.

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

#367
post #363

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…

No I am not referring to that thread. I am referring to the thread further down where someone compares using a memory unsafe language to an illegal activity. If you need an example of the rust community being toxic, I give you https://github.com/actix/actix-web Look up the history and realize they bullied an open source project leader into leaving open source for good.

So this thread? https://news.ycombinator.com/item?id=32879558

I still don't understand the relevance, this neither appears toxic nor to be a discussion of Rust; this looks like they put forward an out-there idea and you didn't care for it, which just seems like a discussion about consumer protection laws. I also don't see the connection from Actix drama to the idea that people are exaggerating the capabilities of Rust or causing problems for other language communities - I don't know much about it, I'm fully willing to believe toxicity was involved, but a breakdown in communication between a maintainer and their community doesn't seem like the behavior we're discussing and I don't see any evidence this was peculiar to Rust and not a phenomenon in open source at large.

I don't want to relitigate some thread I wasn't even a part of, I just don't understand.

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

#368
post #286

Earlier quoted context omitted.

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

Those aren't medical devices.

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

#369
post #286

Earlier quoted context omitted.

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.

I'd like to hear more about that, but I assume it's much like the other poster here that described a Linux system that is a peripheral device attached to the actual medical device that does the medical shit.

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

#370

Earlier quoted context omitted.

because people of modern age have to destroy everything's good, to feel better about themselves, without having to actually be good.

Sort of how Linus pisses on Rust with a not-actually-good argument?

Linus is not pissing on Rust though, his argument is about panic in Kernel code.

Why people feel attacked by Linus words is a mystery to me.

Post reply on HN