Rust Support Merged into Linux Kernel | Hacker News Reader

Rust Support Merged into Linux Kernel

git.kernel.org

79 pointshasheddan10 comments

Very excited to see this happen!

If I may plug the tiny little aspect of this I was involved in, check out https://github.com/rust-lang/rfcs/pull/3271 .

It's a long way off, and it's important to point out the following is not guaranteed to happen so as not to scare off the old hands worried about too much change too quick, but it's interesting to wonder about where this might eventually lead.

Things I would like to see:

1. The above, make sure alloc is good enough for the Kernel for the occasional dynamic memory management one needs to do.

2. Cargo support. Cargo -> {kbuild, Bazel, Nix, ...} should be really slick and easy to do.

3. Out-of-tree code is no longer verboten, because offline support with "Cargo->kbuild" is good and not a source of indeterminism.

4. Drivers and other "periphery code" in Rust increasingly uses enforced minimal interfaces, is reusable in other OS projects.

5. Even Core kernel functionality broken into parts. Think how https://lwn.net/Articles/880175/ is trying to separate concerns for speed, do that for modularity instead.

6. "Linux" is increasingly not a single multi-million line monolith, but a collection of parts that can be composed together in myriad different ways to build different things. "Composition over configuration" as this supercedes linux's current way of supporting diverse use-cases which is 2^large-number configuration options which have no hope of all being tested or well understood, and few correct-by-construction guarantees over that space.

This is all speculative and multiple decades off, but Linux will probably outlive us unless the nukes go off first so we might as well dream.

Given that many Rust's security guarantees can't hold in the kernel, what is its advantage over Ada, Nim or Zig?

- safety is not binary. Some security guarantee are still better than none. (And most security guarantees of Rust still holds in the kernel)

- Rust is at this moment more mature and stable than Zig or Nim with a more broad ecosystem. I don't know much about Ada but I think there are some technical issues there.

Nim's very GC-oriented which just isn't great/usable for the kernel. Yes, you can turn it off and allocate/deallocate manually, but then you barely gain anything on top of C apart from an oop system.

Zig isn't improving correctness too much either. It provides some niceties, but no guarantees around correctness if I understand correctly. It's not trivial - here's a whole post about it https://www.scattered-thoughts.net/writing/how-safe-is-zig/

My understanding is that nim's arc memory management strategy inserts frees where it can automatically without being a GC, and that rust actually does something similar in many cases. Nim's arc doesn't handle cycles, and there is a more GC-like orc strategy. Even using only arc (and refraining from cyclic data structures or handling those specially) still seems better than "barely ... anything on top of C apart from an oop system".

> many Rust's security guarantees can't hold in the kernel

I'm not sure what you're referring to?

Maybe that kinderkarten stuff ?

https://news.ycombinator.com/item?id=33056077

https://lkml.org/lkml/2022/9/19/1105

This is a misread of those posts. Both say nothing about Rust's security features in the kernel.

> Given that many Rust's security guarantees can't hold in the kernel, what is its advantage over Ada, Nim or Zig?

Rust's security guarantees can hold in Rust code that's written for the kernel though. I'm not sure where you got the idea that they can't hold.

Nim has a GC, so that's completely out from being used in the kernel and Zig doesn't offer any security benefits that aren't just slow runtime checks.

Your question is based on false premise.

Reply on news.ycombinator.com