Live data from Hacker News

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

lkml.org

81–90 of 542 posts

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

#81
As usual HN comments react to the headline, without reading the content.

A lot of modern userspace code, including Rust code in the standard library, thinks that invariant failures (AKA "programmer errors") should cause some sort of assertion failure or crash (Rust or Go `panic`, C/C++ `assert`, etc). In the kernel, claims Linus, failing loudly is worse than trying to keep going because failing would also kill the failure reporting mechanisms.

He advocates for a sort of soft-failure, where the code tells you you're entering unknown territory and then goes ahead and does whatever. Maybe it crashes later, maybe it returns the wrong answer, who knows, the only thing it won't do is halt the kernel at the point the error was detected.

Think of the following Rust API for an array, which needs to be able to handle the case of a user reading an index outside its bounds:

  struct Array { ... }
  impl Array {
    fn len(&self) -> usize;

    // if idx >= len, panic
    fn get_or_panic(&self, idx: usize) -> T;

    // if idx >= len, return None
    fn get_or_none(&self, idx: usize) -> Option;

    // if idx >= len, print a stack trace and return
    // who knows what
    unsafe fn get_or_undefined(&self, idx: usize) -> T;
  }
The first two are safe by the Rust definition, because they can't cause memory-unsafe behavior. The second two are safe by the Linus/Linux definition, because they won't cause a kernel panic. If you have to choose between #1 and #3, Linus is putting his foot down and saying that the kernel's answer is #3.

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

#82
post #32
post #20

Earlier quoted context omitted.

if you panic and you're a kernel you very likely corrupt your filesystem, at the very least.

While I don’t advocate for kernel panics, journaling filesystems are a thing.

Journaling FS can also become corrupted. That's why i don't use XFS (just a quick log replay after a kernel crash. Have some crashes and the FS is corrupted beyond repair.)

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

#83
post #65

Earlier quoted context omitted.

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 .

Just as many people have problems with this form of communication, many people find it hard to clearly express themselves in an environment where they're expected to put people's feelings above all else. What some might perceive as "hostile", others would simply call "honest". It's simply a matter of preference.

No, it’s not “simply a matter of preference” when it causes someone else to be in a hostile work environment. At that point, you’re affecting the lives of those around you. Sure, some people have medical conditions that might prevent them from seeing this, but even they put in an effort to be better. It stops being a “preference” when it actively hurts those around you.

If you are an asshole, are known to be an asshole, have no intention of changing that, and are working with others… maybe don’t. You’re free to work alone, but why make people around you miserable by having to deal with you? Go be an asshole to yourself and let everyone else work together.

It’s shocking that advocating for safe and inclusive work environments is such a controversial topic. If he were any other person, his behavior would be quashed in a second.

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

#84

Earlier quoted context omitted.

I am probably wrong but I understood that “safety meaning panic” is noeither “safe” not allowed in the Linux kernel because the kernel must not panic when an error arises.

Which is why Rust has been accommodating the kernel by adding non-panic versions of the functions that Linus has been complaining about (namely that memory allocation is infallible, because that isn't an unreasonable thing to assume in applicationc code.). Still doesn't change the fact that "safe" in this context has a technical meaning, and what Linus is describing isn't that.

The issue that Linus is probably coming from is that many Rust aficionados evangelize for Rust as if the very specific technical meaning of “safe” in Rust was the generic meaning of “safe”. For those who understand the limitations and the trade-offs, that can be quite tiresome.

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

#85

I’ve been using Rust for a while, and I’m so, so tired of hearing this argument. Yes, we know. We get it. Rust is not an absolute guarantee of safety and doesn’t protect us from all the bugs. This is obvious and well-known to anyone actually using Rust. At this point, the argument feels like some sort of ideological debate happening outside the realm of actually getting work done. It feels like any time someone says…

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

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

#86
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 still believe this is only the tip of iceberg in terms of culture clashes.

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

#87

I’ve been using Rust for a while, and I’m so, so tired of hearing this argument. Yes, we know. We get it. Rust is not an absolute guarantee of safety and doesn’t protect us from all the bugs. This is obvious and well-known to anyone actually using Rust. At this point, the argument feels like some sort of ideological debate happening outside the realm of actually getting work done. It feels like any time someone says…

I think it keeps getting said because there appear to be a lot of people who don't understand this.

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

#88
post #6

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. The comment seemed to be making reference to rust's safety guarantees about undefined behaviour like use after free. Linus' seems to have a completely different definition of "safey" that conflates allocation failures, indexing out of bounds, and division by zero with memory safety.…

From a quick skim, it seems to me that at least in Linus's interpretation, his interlocutor is requesting changes to the way the kernel does things in order to accommodate/maintain Rust's "there is no undefined behaviour; in cases where circumstances conspire to make behaviour undefined, terminate immediately" philosophy even in kernel Rust code. He then figures that if he said he is not willing to do that, the other side would respond with something to the effect of "but implementing the Rust philosophy in full means you get safety, and you surely can't have a goal more important than that", and therefore leaps to talking down the importance of the safety that Rust actually guarantees, to argue that it is not actually so great that all other objectives would be secondary to it.

If his initial interpretation and expectation of the Rustacean response is in fact correct, the line of argumentation does not seem per se wrong, but I do think that it is bad practice in adversarial conversations to do the thing where you silently skip forward several steps in the argument and respond to what you expect (their response to your response)^n to be instead of the immediate argument at hand.

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

#89
post #67

Earlier quoted context omitted.

One of my Marine NCOs would say, "there is no such thing as safe." You aren't safe on the FOB, in your car, in your barracks, or in your house. There are only degrees of safety. Very wise almost globally applicable words.

> There are only degrees of safety. Sure but people use this logic to justify no safety. Find me a marine a that goes into war totally naked.

That's great for them. I dont use it to justify no safety.

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

#90

Why is panicing in the kernel on an error not an option? Like kernels can write a core dump and reboot, right?

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?
Post reply on HN