Three Questions and Answers: Rust for Linux

In Linux 6.1 users could get a glimpse of the Rust-implementation for the first time – although they had to content themselves with a simple "Hello, World!". We spoke with Miguel Ojeda, software engineer and maintainer of Rust for Linux, about the current state and future of the project:

So far, Rust-Support in Linux is experimental. Which features do you plan to add next?

Our primary goal now is to upstream enough abstractions in order to later on submit the first Rust driver to the kernel. These abstractions wrap kernel subsystems into safe APIs so that Rust drivers can be written in safe Rust as much as possible.

The first drivers (and the abstractions supporting them) that will start to be upstreamed are likely to be the Asahi Linux's GPU driver, Android's Binder and the NVMe driver. These are all non-trivial and will set the example for future Rust kernel abstractions and drivers.

While doing this, we also need to ensure that the relevant kernel maintainers get involved as much as possible (e.g. reviewing and commenting the code, taking the code through their tree if possible, etc.).

At the same time, there are several infrastructure improvements in the works, such as an improved build system for Rust code in the kernel and further integration with the kernel testing and documentation systems. In addition, Arm has started upstreaming the Rust support for the AArch64 architecture based on the prototype support we had in Rust for Linux.

There are also very interesting new tools in development such as klint: it allows introducing extra static analysis passes ("lints") in Rust kernel code, leveraging the Rust compiler as a library. One of the first lints being worked on validates that Rust code follows the kernel locking rules by tracking the preemption count at compile-time.

On the toolchain side, there are improvements being worked on, such as kernel CFI support in the Rust compiler, security-related compiler flags, potentially better support for Rust in pahole, etc.

Finally, and perhaps most interesting for non-kernel usage of the Rust language, there are some proposed improvements to the language, library, and tooling that stem from the project. Most notably, the field projection RFC to facilitate accessing the fields of certain wrapper types in an ergonomic and safe way.

Some users complain that progress is too slow. Which unusual challenges do you face with the project?

I am not sure which users the question refers to, but some people argue it is the other way around! For some, for instance, we are going too fast, perhaps because they feel Rust is unproven or immature as a language/toolchain.

So it depends on who you ask. For us, we believe we should be cautious about the code we introduce in the kernel. In particular, it should have been given enough time for reviews and kernel maintainers should be comfortable with accepting it. Not only that, there are many details to be discussed and decided yet, and it is now the time to start doing so within the kernel.

While that process takes time, being already in the kernel brings us other advantages, too. For instance, now companies, other projects, potential users and developers, etc. will start looking at using Rust in the kernel and it increases the support we may receive. In fact, we have started to see the effects of this already!

As for challenges, we have had plenty, of course. An important one has been showing that it is indeed possible to come up with safe abstractions wrapping existing kernel functionality (i.e. without having to rewrite everything in Rust and without compromising on e.g. performance). Personally, coordinating everything has been a challenge, but one I have enjoyed a lot thanks to the people that work within the project and the companies contributing to it.

Once the Rust-Support in Linux is ready for prime time: Which advantages are there for Kernel-Devs as well as regular Linux-users?

For end users and companies, one benefit is clear: to reduce the number of vulnerabilities. Several reports from major companies and software projects have shown that about 70% of vulnerabilities are due to memory safety issues in C/C++ code bases. Therefore, if we are able to remove most of those and/or reduce the severity of vulnerabilities in general, then it hopefully means increased security for end users, fewer number of urgent kernel updates that they may need to apply, fewer breaches for companies, etc.

For kernel developers, Rust brings a lot of modern improvements as a language, library, and tooling compared to C. This is not surprising, given it has been designed with all the hindsight of older languages, as well as recent advances in research. In our opinion, this will also mean less logic bugs overall in the kernel, less debugging time, better ergonomics, etc. And all this, in turn, suggests more productivity for companies that employ engineers to work on the kernel, as well as more reliable drivers for end users. The first testimonials to that effect have already appeared from the developers of the initial Rust drivers.

For kernel maintainers, they will ideally be more confident in accepting patches and refactoring code in their subsystems, for similar reasons. For instance, if a patch changes a safe Rust driver, it should not be possible to introduce a memory safety issue in the kernel that way, where the stakes are higher than in userspace. We believe that extra “layer” of protection that Rust gives to source code is very valuable.

Finally, for the kernel, we hope to see new generations of young developers try kernel development thanks to the fresh language and technologies in use. Ideally, all this will help Linux to continue being the most widely deployed kernel in the world for decades to come.

Miguel, thanks for the interview! Readers who want to know more about Rust for Linux can find additional information on the project's website. The German version of the interview is available here.

(fo)