It will be unblocked if we run the following command from another shell because it increments the value by 1, which allows the original read to complete: When semaphore is a newly initialized device, the command above will block because the device's current value is 0. We can interact with it from the shell as follows: Suppose semaphore is a file representing our device. Each device has a current value writes of n bytes result in the device value being incremented by n reads decrement the value by 1 unless the value is 0, in which case they will block until they can decrement the count without going below 0. We'll use an implementation of a semaphore character device. Let’s get into a few examples of how Rust can assist kernel developers in writing drivers that are safe and correct.

Just as important as safety, Rust support needs to be convenient and helpful for developers to use. For example, we have specific machine-checked requirements around the usage of unsafe code: for every unsafe function, the developer must document the requirements that need to be satisfied by callers to ensure that its usage is safe additionally, for every call to unsafe functions (or usage of unsafe constructs like dereferencing a raw pointer), the developer must document the justification for why it is safe to do so. Since Rust is a new language for the kernel, we also have the opportunity to enforce best practices in terms of documentation and uniformity. We also need designs that allow code in the two languages to interact with each other: we're particularly interested in safe, zero-cost abstractions that allow Rust code to use kernel functionality written in C, and how to implement functionality in idiomatic Rust that can be called seamlessly from the C portions of the kernel. We joined the Rust for Linux organization, where the community had already done and continues to do great work toward adding Rust support to the Linux kernel build system. We believe this incremental approach allows us to benefit from the kernel’s existing high-performance implementation while providing kernel developers with new tools to improve memory safety and maintain performance going forward. The Linux kernel has over 30 million lines of code, so naturally our goal is not to convert it all to Rust but rather to allow new code to be written in Rust.

We developed an initial prototype of the Binder driver to allow us to make meaningful comparisons between the safety and performance characteristics of the existing C version and its Rust counterpart. 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.

We feel that Rust is now ready to join C as a practical language for implementing the kernel. On Android, vulnerabilities in the kernel are generally considered high-severity because they can result in a security model bypass due to the privileged mode that the kernel runs in. However, memory safety bugs do still regularly occur. Density of memory safety bugs in the Linux kernel is generally quite low due to high code quality, high standards of code review, and carefully implemented safeguards. In this post, we discuss some technical aspects of this work using a few simple examples.Ĭ has been the language of choice for writing kernels for almost half a century because it offers the level of control and predictable performance required by such a critical component. Related to this, we are also participating in the effort to evaluate the use of Rust as a supported language for developing the Linux kernel. In our previous post, we announced that Android now supports the Rust programming language for developing the OS itself. Posted by Wedson Almeida Filho, Android Team