LWN: Comments on "Next steps for Rust in the kernel"

Next steps for Rust in the kernel

tialaramex — Wed, 21 Sep 2022 23:10:40 +0000

Crucial in Rust culture is also writing safety rationales. Here's a nice succinct one from the implementation of alloc::vec::Vec

// SAFETY: After filling holes, all items are in contiguous memory.

These should live next to unsafe { /* ... */ } blocks, the compiler can't read your safety rationale, but a human can, and it can really help distinguish between cases where you're an idiot and this code, though it looked wrong to you, is correct; and cases where you're a genius, and this code even though it looked right to its author is actually wrong and needs fixing. If the safety rationale makes a claim that is false, that's a problem. At the least, we need a patch to the rationale. But, maybe the code is wrong too.

Next steps for Rust in the kernel

Tuna-Fish — Wed, 21 Sep 2022 14:11:57 +0000

How? By the time Rust will be used for anything other than toy drivers, Rust-GCC should be done, so Linux with Rust will compile anywhere that Linux without Rust can.

Next steps for Rust in the kernel

khim — Wed, 21 Sep 2022 13:40:37 +0000

So very true. Unsafe Rust forms TCB which “normal” safe Rust uses to implement “business logic”.

But unsafe keyword is better. I worked on a codebase which was similarly separated into “trusted” and “untrusted” components.

And newcomers invariably tried to add stuff to the “trusted” side! I guess logic was: it's “trusted”, thus it's obviously “better”.

But unsafe just doesn't feel like that. People know you can add unsafe code, but the name itself prompts them to be careful.

Next steps for Rust in the kernel

khim — Wed, 21 Sep 2022 13:30:00 +0000

> Both would have to be per-file opt-ins, of course.

Except it's not really possible. Think something like std::align: if such low-level functions are not properly marked that all these “escape analysis” quickly turns into farce.

In theory it should be possible to keep “new, clean code” and “old, dirty, code” clearly separated and then slowly rewrite things, but if you consider how long it takes to, e.g., remove strlcpy… it doesn't look feasible at all.

Next steps for Rust in the kernel

Wol — Wed, 21 Sep 2022 13:21:20 +0000

> The "unsafe" keyword allows unrestricted liberties, including inline assembly. Interestingly, "unsafe" can also be read as "trusted". Safe Rust doesn't trust, it verifies.

Hmmm, that's a VERY interesting take ...

Cheers,
Wol

Next steps for Rust in the kernel

oxidizer — Wed, 21 Sep 2022 13:03:03 +0000

Good comments about C, however Rust doesn't have an issue here.

The "unsafe" keyword allows unrestricted liberties, including inline assembly. Interestingly, "unsafe" can also be read as "trusted". Safe Rust doesn't trust, it verifies.

Next steps for Rust in the kernel

Wol — Wed, 21 Sep 2022 10:52:52 +0000

This is the classic Pascal / Modula dichotomy.

If you try and enforce correctness, the language becomes unusable. Especially if you try and enforce the *wrong* mathematical model (Which is why I rail against SQL and relational - imnsho they've picked the wrong model, sets instead of lists ...). (Correctness is a property of a mathematical model, not of the scientific "does it actually work in the real world.)

C just doesn't have a model. C++ appears to try and impose a model on top of C.

Where Rust appears to score is that like Modula-2, it has a "strict model with escape hatches". So like C you can do anything, but the language makes it absolutely clear that you are gambling with whether it will work ...

And the problem with C is that the gcc guys are apparently trying to enforce a model that does not mesh with the way the kernel works, hence all these "escape hatch" flags, and maybe why some kernel guys are keen to try Rust. Modula-2 was before its time ... :-)

Cheers,
Wol

Next steps for Rust in the kernel

linusw — Wed, 21 Sep 2022 09:03:38 +0000

As I was rambling on in my own little bubble over at the kernelorg blog about Rust, I came to the conclusion that what we are doing with Rust is to increase the abstraction of the language, not just making it more safe, but abstraction does bring safety. But since this point has been stressed since 1968 there is a reason why C has prevailed, and it is exactly the (casting) and general ability to act like a big macro assembler. Doing C safe would mean to remove exactly these features and thereby remove the appeal of C. (This is not really my opinion, but extrapolated from Niklaus Wirth.)
https://people.kernel.org/linusw/rust-in-perspective

Next steps for Rust in the kernel

pbonzini — Wed, 21 Sep 2022 06:51:57 +0000

The idea was to start with very simple stuff like forcing manual conversion of integer types and explicitly noting in the prototypes which pointer arguments that are can escape the called functions. Both would have to be per-file opt-ins, of course.

Next steps for Rust in the kernel

taladar — Wed, 21 Sep 2022 05:56:19 +0000

What is it with all those people who don't understand that many (especially safety) features can not be retrofitted into established languages while maintaining backwards compatibility?

Either you end up with something that accepts all existing programs (maintains backwards compatibility) or with something that rejects the existing programs that do unsafe things, both isn't possible at the same time.

Of course the desire to keep the old code around is also at odds with significantly improving it. If you have a language with significantly improved idioms and safety features (e.g. Rust's Result instead of inline error codes) you would still have to deal with the fact that 99% of your code is written to not take advantage of them. And if you have to rewrite all your code anyway, why not rewrite it in a safer new language?

In my experience two languages that are very similar (e.g. C and C+retrofitted safety features) are much harder to keep apart in your head too than two languages that are significantly different.

Next steps for Rust in the kernel

mirabilos — Tue, 20 Sep 2022 22:28:26 +0000

This is an unportable catastrophe…

Next steps for Rust in the kernel

jhoblitt — Tue, 20 Sep 2022 01:38:39 +0000

People who live in C houses shouldn't (void)stones.