The past few years Google engineers have been reimplementing Android’s Binder driver in the Rust programming language. Binder is a critical part of Android for inter-process communication (IPC) and now with Linux 6.18 it looks like the Rust rewrite will be upstreamed.
Queued this week into Greg Kroah Hartman’s char-misc-next Git branch is the Rust Binder driver. With it making it into the char/misc area’s “next” branch, it’s expected to be submitted for the upcoming Linux 6.18 merge window kicking off in the next week or two.
As for this major rewrite of the Android Binder IPC kernel driver in Rust, Google engineer Alice Ryhl explains with the patch adding the new Rust Binder driver:
“We’re generally not proponents of rewrites (nasty uncomfortable things that make you late for dinner!). So why rewrite Binder?
Binder has been evolving over the past 15+ years to meet the evolving needs of Android. Its responsibilities, expectations, and complexity have grown considerably during that time. While we expect Binder to continue to evolve along with Android, there are a number of factors that currently constrain our ability to develop/maintain it. Briefly those are:
1. Complexity: Binder is at the intersection of everything in Android and fulfills many responsibilities beyond IPC. It has become many things to many people, and due to its many features and their interactions with each other, its complexity is quite high. In just 6kLOC it must deliver transactions to the right threads. It must correctly parse and translate the contents of transactions, which can contain several objects of different types (e.g., pointers, fds) that can interact with each other. It controls the size of thread pools in userspace, and ensures that transactions are assigned to threads in ways that avoid deadlocks where the threadpool has run out of threads. It must track refcounts of objects that are shared by several processes by forwarding refcount changes between the processes correctly. It must handle numerous error scenarios and it combines/nests 13 different locks, 7 reference counters, and atomic variables. Finally, It must do all of this as fast and efficiently as possible. Minor performance regressions can cause a noticeably degraded user experience.
2. Things to improve: Thousand-line functions, error-prone error handling, and confusing structure can occur as a code base grows organically. After more than a decade of development, this codebase could use an overhaul.
3. Security critical: Binder is a critical part of Android’s sandboxing strategy. Even Android’s most de-privileged sandboxes (e.g. the Chrome renderer, or SW Codec) have direct access to Binder. More than just about any other component, it’s important that Binder provide robust security, and itself be robust against security vulnerabilities.
It’s #1 (high complexity) that has made continuing to evolve Binder and resolving #2 (tech debt) exceptionally difficult without causing #3 (security issues). For Binder to continue to meet Android’s needs, we need better ways to manage (and reduce!) complexity without increasing the risk.
The biggest change is obviously the choice of programming language. We decided to use Rust because it directly addresses a number of the challenges within Binder that we have faced during the last years. It prevents mistakes with ref counting, locking, bounds checking, and also does a lot to reduce the complexity of error handling. Additionally, we’ve been able to use the more expressive type system to encode the ownership semantics of the various structs and pointers, which takes the complexity of managing object lifetimes out of the hands of the programmer, reducing the risk of use-after-frees and similar problems.”
The Rust Binder driver has been tested on the Android emulator as well as a Google Pixel 6 Pro. The Rust Binder driver does implement all features that the C binder driver supports.
Barring any last minute objections or issues raised by Linus Torvalds, it looks like for the upcoming Linux 6.18 cycle will be the first major Rust kernel driver to be used by future Android devices.
