Rust in the Linux kernel: part 2(lwn.net)
lwn.net
Rust in the Linux kernel: part 2
https://lwn.net/SubscriberLink/1025232/fbb2d90d084368e3/
72 comments
Some drivers written in Rust instead of C would need to be littered with unsafes, raw pointers, pointer arithmetic, manual memory management, manual layout control, and manual resource management to retain similar behaviors. I’m assuming someone’s ideal would be for the entire kernel to be rewritten in Rust? When all that is said and done, will it be worth the effort? It’d seem as though you’d have a lot of the same problems, and new ones around timing and performance if you start handling memory differently, like jitteriness, lags, OOM (letting resource usage get out-of-hand), lock-ups, or worse, unless it’s well-tested. I have nothing against Rust, and writing new drivers in Rust selectively would be fine, but I could see it going this way and am curious. To be absolutely clear, Rust is not bad; I just wonder about introducing complexity in maintenance of the kernel by having variation in memory management, because I’d almost rather have a diagnosable memory leak that’s well-tested for than “I have no idea what’s going on.”
> Some drivers written in Rust instead of C would need to be littered with unsafes, raw pointers, pointer arithmetic,
The main safety benefit of Rust in a low-level environment is not that you never have to write unsafe code; it's that the language allows you to encapsulate unsafe code and express its safety invariants in the type system. My go-to example of this is the Vec type in the standard library. The language doesn't have any notion of a growable array built-in; it's defined in pure Rust code in the standard library using some unsafe code that exposes a fully safe API. And using the invariants expressed in that API, the compiler can prove the safety of any user code that uses a growable array, under the axiom that the unsafe definition of Vec was correct.
The standard library is rich enough that application developers never really have to touch unsafe, and that's great for them -- but for those of us doing systems programming, this "axiomatic safety" (as I like to think of it) is the real power of Rust. We can do complicated and unsafe things (like direct hardware access, complicated pointer tricks, concurrent data structures, etc.), write out the invariants users need to uphold in order for the code to be sound, and then the compiler can prove the program safe under the assumption that our unsafe building blocks are sound. Well-written Rust isn't "littered with unsafes" everywhere; the unsafe code only appears in low-level definitions of data structures and hardware/foreign function interfaces, and the rest of the code is written in safe Rust.
> manual memory management, manual layout control, and manual resource management to retain similar behaviors.
All of these things are manual in Rust. There's no GC and the compiler does not insert allocations or deallocations; it's all done by user or library code. Layout is entirely controlled by the programmer (the compiler does optimize struct layout by default, but you can opt out by marking the struct #[repr(C)]).
Rust is not garbage collected, and there is no automatic memory management of any kind. The philosophy is: you manage memory manually, and the compiler checks your work to make sure you didn't make a mistake. The only real difference from C (besides the safety guarantees) is that Rust has destructors, so you can use RAII to simplify cleanup/freeing.
The main safety benefit of Rust in a low-level environment is not that you never have to write unsafe code; it's that the language allows you to encapsulate unsafe code and express its safety invariants in the type system. My go-to example of this is the Vec type in the standard library. The language doesn't have any notion of a growable array built-in; it's defined in pure Rust code in the standard library using some unsafe code that exposes a fully safe API. And using the invariants expressed in that API, the compiler can prove the safety of any user code that uses a growable array, under the axiom that the unsafe definition of Vec was correct.
The standard library is rich enough that application developers never really have to touch unsafe, and that's great for them -- but for those of us doing systems programming, this "axiomatic safety" (as I like to think of it) is the real power of Rust. We can do complicated and unsafe things (like direct hardware access, complicated pointer tricks, concurrent data structures, etc.), write out the invariants users need to uphold in order for the code to be sound, and then the compiler can prove the program safe under the assumption that our unsafe building blocks are sound. Well-written Rust isn't "littered with unsafes" everywhere; the unsafe code only appears in low-level definitions of data structures and hardware/foreign function interfaces, and the rest of the code is written in safe Rust.
> manual memory management, manual layout control, and manual resource management to retain similar behaviors.
All of these things are manual in Rust. There's no GC and the compiler does not insert allocations or deallocations; it's all done by user or library code. Layout is entirely controlled by the programmer (the compiler does optimize struct layout by default, but you can opt out by marking the struct #[repr(C)]).
Rust is not garbage collected, and there is no automatic memory management of any kind. The philosophy is: you manage memory manually, and the compiler checks your work to make sure you didn't make a mistake. The only real difference from C (besides the safety guarantees) is that Rust has destructors, so you can use RAII to simplify cleanup/freeing.
For what it’s worth, the Rust driver pointed to in the article doesn’t have a single unsafe block, raw pointer, pointer arithmetic, or any of those other things you mentioned.
It’s a simple driver. But it’s also possible that rust code doesn’t necessarily have to copy the C code line for line - the C way of doing things with pointer arithmetic may just not be necessary with the abstractions rust provides.
It’s a simple driver. But it’s also possible that rust code doesn’t necessarily have to copy the C code line for line - the C way of doing things with pointer arithmetic may just not be necessary with the abstractions rust provides.
It's basically a "Hello, World" type of driver. A "Hello, World" in C or Rust typically also doesn't involve unsafe blocks or safety issues.
In Rust you know there is no memory issue because there is no unsafe block. In C you don't know if there is no memory issue, there are many way to write a hello world that has memory issue.
Even complex driver in rust will have very little amount of unsafe because of correct use of (often zero cost) abstractions. And it is much less mental drain to check only that, than when every single line is a minefield that could hide undefined behavior
char hello[5] = "Hello";
Even complex driver in rust will have very little amount of unsafe because of correct use of (often zero cost) abstractions. And it is much less mental drain to check only that, than when every single line is a minefield that could hide undefined behavior
> Some drivers written in Rust instead of C would need to be littered with unsafes, raw pointers, pointer arithmetic, manual memory management, manual layout control, and manual resource management to retain similar behaviors.
Some might, the extent remains to be seen. Of course there needs to be code that has unsafe memory management, but a small amount of very well checked code that creates safe wrappers can eliminate the possibility of bad memory handling in huge chunks of the remaining logic. It doesn't eliminate the errors 100% of course, and that's OK - reducing the quantity, search space, and even possibility of a lot of bugs is still a good thing, as it means correctness can be acheived with less time and effort.
> I’m assuming the goal is to have the entire kernel rewritten in Rust.
Who's goal? Some people may want to see that sure. Plenty of others are happy just because this experiment is allowing Rust itself to improve as the r4l people are effectively pushing rust into territory it hasn't been used in previously. Some people just want to see rust in drivers since they are often a pain to keep porting around as internal kernel apis change, and having safe rust abstractions around the tricky bits makes that porting effort much easier.
> Because you’ll have a lot of the same problems, and it seems you could introduce new ones around timing and performance if you start handling memory differently.
If you have a driver so sensitive to timing and performance that a small amount of memory handling change can break it - you'll have these issues whenever the C code around memory management changes as well. There are regularly changes to memory allocation, scheduling, etc within the kernel anyway, so I think this concept is a bit of a moot concern.
Some might, the extent remains to be seen. Of course there needs to be code that has unsafe memory management, but a small amount of very well checked code that creates safe wrappers can eliminate the possibility of bad memory handling in huge chunks of the remaining logic. It doesn't eliminate the errors 100% of course, and that's OK - reducing the quantity, search space, and even possibility of a lot of bugs is still a good thing, as it means correctness can be acheived with less time and effort.
> I’m assuming the goal is to have the entire kernel rewritten in Rust.
Who's goal? Some people may want to see that sure. Plenty of others are happy just because this experiment is allowing Rust itself to improve as the r4l people are effectively pushing rust into territory it hasn't been used in previously. Some people just want to see rust in drivers since they are often a pain to keep porting around as internal kernel apis change, and having safe rust abstractions around the tricky bits makes that porting effort much easier.
> Because you’ll have a lot of the same problems, and it seems you could introduce new ones around timing and performance if you start handling memory differently.
If you have a driver so sensitive to timing and performance that a small amount of memory handling change can break it - you'll have these issues whenever the C code around memory management changes as well. There are regularly changes to memory allocation, scheduling, etc within the kernel anyway, so I think this concept is a bit of a moot concern.
>The next article in this series will look at the design of the interface between the C and Rust code in the kernel, as well as the process of adding new bindings when necessary.
This is the actual useful one since so little of the kernel has Rust bindings. When I tried to implement a filesystem driver in rust I spent most of my time trying to write bindings instead of trying to write a filesystem.
This is the actual useful one since so little of the kernel has Rust bindings. When I tried to implement a filesystem driver in rust I spent most of my time trying to write bindings instead of trying to write a filesystem.
Did you try bindgen? Because it’s extremely good and efficient imo.
There are projects that make more sense:
https://arxiv.org/abs/2506.03876
https://github.com/asterinas/asterinas
The reasons we encounter pattern issues forcing Linux into a polyglot is not a new phenomena:
https://en.wikipedia.org/wiki/Second-system_effect
Best regards =3
https://arxiv.org/abs/2506.03876
https://github.com/asterinas/asterinas
The reasons we encounter pattern issues forcing Linux into a polyglot is not a new phenomena:
https://en.wikipedia.org/wiki/Second-system_effect
Best regards =3
globalnode(12)