Using Rust to Write Safe and Correct Linux Kernel Drivers

Write for InfoQ

As part of the Rust for Linux project, aimed to make it possible to use Rust for Linux driver development, the Android team at Google is working on evaluating the benefits that using Rust would bring.

Rust for Linux was announced by Miguel Ojeda approximately one year ago on LKML, the Linux Kernel Mailing List, as an attempt to bring a second language to Linux kernel development by extending the Linux build system. Specifically, the project seeks to enable the use of Rust to write drivers and other "leaf" kernel modules, but not for the kernel core or the major kernel subsystems.

We feel that Rust is now ready to join C as a practical language for implementing the kernel. It can help us reduce the number of potential bugs and security vulnerabilities in privileged code while playing nicely with the core kernel and preserving its performance characteristics.

Extending the Linux build systems is only part of the picture, says Wedson Almeida Filho, who works in the Android team. Indeed, for Rust to be a first-class citizen in Linux kernel development, an interop mechanism is also required to safely and efficiently call code written in Rust from C portions of the kernel and viceversa.

To show how Rust could help Linux driver developers write correct and safer code, Almeida Filho compares in his article two implementations of a simple semaphore character device, in C and in Rust. This allows him to pinpoint several tasks that driver implementations commonly execute where Rust guarantees apply.

For example, leveraging Rust's ownership model it is possible to pass a Rust object to some C code, have this call functions implemented in Rust, then give the object ownership back to the Rust side. Doing this will enforce correct lifetime management as long as the C code is written correctly.

Another area where Rust provisions help is the use of non-mutable references. For example, passing around non-mutable self prevents that object from being modified unless so-called interior mutability is used. This entails wrapping mutant code in a Mutex<T> or SpinLock<T> which can be checked at compile-time to prevent a developer from inadvertently changing the state without first acquiring a lock.

Rust also makes it safer to manage shared per-device state, again using a non-mutable reference to a device-specific trait that is passed around to all objects associated to that device.

Almeida Filho also discusses a number of benefits developers can get from Rust when implementing a custom ioctl handler, specifically through the use of a dispatcher to automatically create memory access helpers that will prevent typical errors when dealing with low-level memory, such as buffer overflow, read/write mixing, and so on.

Those are just a few examples. To prove Rust advantage when writing Linux drivers, the Android team is working on porting the Binder IPC driver, which is used for inter-process communication (IPC) on Android and was accepted in 2015 in the Linux kernel, to Rust, which is already in good shape.

At the moment we have nearly all generic kernel functionality needed by Binder neatly wrapped in safe Rust abstractions.

Almeida Filho's article includes many more details than can be summarized here, so make sure to read it if you are interested.

Related Topics:

• Development
• System Programming
• Linux
• Rust
• Safety

We protect your privacy.