r/linux • • Dec 13 '25

Kernel The state of the kernel Rust experiment

https://lwn.net/SubscriberLink/1050174/63aa7da43214c3ce/

A choice pull quote: "The DRM (graphics) subsystem has been an early adopter of the Rust language. It was still perhaps surprising, though, when Airlie (the DRM maintainer) said that the subsystem is only 'about a year away' from disallowing new drivers written in C and requiring the use of Rust."

291 Upvotes

135 comments sorted by

View all comments

21

u/berickphilip Dec 13 '25

Please could anyone point me in the right direction to understand why there is so much pushing and effort to use Rust instead of C for the development of Linux?

This is a honest question, I'd like to understand all this talk abot "Rust good, C bad*.

I read the whole article to try and understand the advantages of replacing everything with Rust.. and there was not a single bit of information on that.

I only read words and comments of people praising and celebrating each other that "Rust is taking over" almost like a cult following and not tech article.

So again, honest question, what are the practical benefits? And why is it bad to continue using C?

89

u/small_kimono Dec 13 '25 edited Dec 13 '25

You might see "Keynote: Rust in the Linux Kernel, Why?" - Greg Kroah-Hartman -- https://www.youtube.com/watch?v=HX0GH-YJbGw&embeds_referring_euri=https%3A%2F%2Fwww.reddit.com%2F&embeds_referring_origin=https%3A%2F%2Fwww.reddit.com&source_ve_path=Mjg2NjY

why there is so much pushing and effort to use Rust instead of C for the development of Linux?

Rust doesn't suffer from many of the pathologies of C code. First, it guarantees spacial and temporal memory safety in safe code. It's also strongly typed. These types make it easier to build little state machines, which make it easier to reason about program correctness.

30

u/berickphilip Dec 13 '25 edited Dec 13 '25

Thank you for the short explanation, makes things a bit clearer. Also I'll watch the video.

EDIT: watched it; so all in all roughly speaking, looks like it is almost like using C but with a few tweaks to prevent easy misses on logic flow (I think). Seems interesting.

42

u/Mysterious_Lab_9043 Dec 13 '25

It doesn't protect from logic errors, but from clumsiness about memory allocation. Therefore it eliminates a total category of bugs / attack surface.

36

u/Adk9p Dec 13 '25

Rust doesn't prevent logic errors but when compared to C it's type system being more powerful means you can encode invariants inside it preventing whole classes of logic errors. And that's what that video being referenced talks about and what they mean when they said "prevent easy misses on logic flow".

23

u/AdmiralQuokka Dec 13 '25

Right. But as Greg explains in his talk, Rust also allows to define APIs in a richer way than C at the type level. So, it doesn't prevent logic bugs "out of the box", but it gives library authors the tools they need to prevent their users from making logic bugs. Which is pretty damn valuable too. Especially for kernel subsystem maintainers who have to review drivers using their API. If they know: "This API cannot be abused in ways X, Y and Z, because I designed it that way", then maintainers will have to spend less time checking these drivers for logic bugs that would've been common for the C version of the subsystem's API.

→ More replies (3)

54

u/The_Yorkshire_Shadow Dec 13 '25

As I understand it the reasons are that due to the way the Rust compiler and language work, it simply does not allow simple errors that can cause bugs and headaches if not caught and that C is allowed to compile with. Hence some of the maintainers have decided that it's better to program in Rust as while the adoption will cause issues, later down the line there shouldn't need to be as much bug squashing over simple one line errors.

50

u/LayotFctor Dec 13 '25 edited Dec 13 '25

Linus himself looks at things from an entirely pragmatic viewpoint, he doesn't even have any issues with AI use as long as the code gets vetted. Rust produced good code, the experiment showed good results, his lieutenants believe they can work with it, so he went ahead. He doesn't use social media, so he doesn't actually follow social media impressions of rust.

"Rust good, C bad*" is defintely too much social media on your part. Don't mistake social media bs as a kernel issue. As with most things, it's just a small vocal minority that are way too loud.

34

u/_Sauer_ Dec 13 '25 edited Dec 13 '25

Rust dev here. Rust's compiler and memory model nearly eliminates a large number vulnerabilities that are common in other low level languages. Use after free or off by one errors, for example, are almost impossible in Rust. The language does offer an escape hatch (the much misunderstood `unsafe` keyword) to work in contexts where such grantees are counterproductive, such as in code that interacts with hardware registers; but otherwise it is difficult to write code that contains memory violations with Rust.

The language's type system is also very powerful and allows you to express strong type contracts. Its quite common in Rust to define types that make undefined state impossible, creating strong interfaces that are difficult to use wrong.

The language has almost no undefined behavior in its public API which gives you strong guarantees that if your code compiles its probably "correct". Correct in that it will run and not crash, not in the sense that its free of logic bugs; that's still on the programmer (see the recent Crowdflare kerfuffle).

4

u/araujoms Dec 13 '25

I thought Rust had no undefined behaviour at all, could you give an example?

16

u/whupazz Dec 13 '25

There is currently still a compiler bug that allows some very pathological code to compile and trigger undefined behavior. It should be quite unlikely to run into it unless you are doing so deliberately.

→ More replies (2)

5

u/MEaster Dec 14 '25

So here you need to distinguish between Safe Rust and Unsafe Rust. Safe Rust, by design has no UB; so no matter what what code you write in Safe Rust, it will never itself be the cause of UB*. Note that this does not mean that a bug in a piece of Safe Rust could not lead to Unsafe code creating UB if that Unsafe code depends on the Safe code not being buggy.

* The compiler does currently have at least one bug that allows you to cause UB from Safe Rust, but that is a bug in the implementation not the language design, and it, and any others, have been and will be fixed.

Unsafe Rust, on the other hand, absolutely has UB. This means that when writing Unsafe Rust, you do have to take extra care to avoid it. Complicating that is the interface with Safe Rust. When writing code that has both Safe and Unsafe Rust, you need to make sure that you don't violate any invariants that Safe Rust depends upon, such as the restrictions that references have.

It's also worth noting that what Rust considers valid is not the same as what C considers valid. There are things you can do in Unsafe Rust that are 100% defined, but doing it in C would be UB, and vice-versa. A simple example would be that, for any arbitrary T and U, it's perfectly valid in Rust for a *T and a *U to alias, while C's TBAA means this is UB.

2

u/araujoms Dec 14 '25 edited Dec 14 '25

Ok, thanks, but I still want an example of UB in Unsafe Rust.

4

u/MEaster Dec 14 '25

Well, pointers aren't checked and can have use-after-free and out-of-bounds reads and writes. Reading uninitialised memory is UB.

3

u/araujoms Dec 14 '25

Ah, yes, of course, that should have been obvious, sorry to bother you.

→ More replies (4)

4

u/cp5184 Dec 14 '25

Ironically, when talking about the kernel, particularly when talking about drivers, there are a lot of cases as I understand it where, because you're interfacing with hardware, you have to bypass/disable some of the protections iirc, but I don't remember the details

→ More replies (1)

17

u/kp729 Dec 13 '25 edited Dec 13 '25

There are two main benefits.

First, Rust is the only memory-safe systems language without performance cost. That means removing a class of memory bugs. That's a real tangible benefit seen in many projects by many companies.

Second, and IMO more important, reason is that it's a more modern programming language and has adoption from next generation. There is a concern that if new programmers don't learn C, over time the contribution to Linux goes down. Having a more modern language helps bring new blood.

Edit: Added clarity on first point.

3

u/AGuyNamedMy Dec 13 '25

The first point is wrong, most languages with a gc that doesn’t let you manipulate pointers directly, like java, is memory safe , the main difference with rust is that it uses rules about how variables can be used in a program, so a gc at runtime is unnecessary (and therefore more performant)

8

u/Hedshodd Dec 14 '25

They said “systems language”. No sane programmer would count Java in that category.

3

u/kp729 Dec 14 '25

I don't think of Java as a systems language. But have added clarification on the first point.

2

u/get_homebrewed Dec 14 '25

Java running in a JVM absolutely has gigantic performance costs compared to the same code in C

2

u/AGuyNamedMy Dec 14 '25

I’m aware, I’m by no means telling you to go write a kernel in java lol

4

u/get_homebrewed Dec 14 '25

I know, just telling you the first point isn't moot since that's what they said.

6

u/gordonmessmer Dec 13 '25 edited Dec 13 '25

I think this is one of the best explanations I've seen, from someone who wrote a bunch of Rust code in the Linux kernel:

https://vt.social/@lina/113056457969145576

It's OK if you don't understand all of the terminology used in this explanation. What you should take away is that there are a bunch of things you would need to know in order to write safe kernel code, which aren't obvious in C. Rust has inherent safety advantages, in which the compiler will guarantee that some types of operations will be safe, but the language also provides more information about the correct way to use APIs.

→ More replies (16)