The Binder driver, the inter-process communication mechanism every Android device depends on, is losing its C implementation. Google engineer Carlos Llamas posted the patch removing roughly 11,000 lines of it, and Greg Kroah-Hartman has queued the removal into char-misc-next for the Linux 7.4 merge window.

This is a first. Rust in the kernel has to date meant new drivers, or a Rust version living beside a C one. This is a C driver being deleted because the Rust replacement won.

What Llamas wrote

“The day has finally come. We are dropping the legacy C implementation of the Binder IPC driver in favor of its Rust version.

For 15+ years, the C driver has grown increasingly complex, making it incredibly painful to maintain and land new features without tripping over vulnerabilities. The Rust implementation alleviates most of these issues, so it’s time for a change.

Alice Ryhl has worked hard on the Rust binder for the past couple of years, not only achieving full feature parity but also proving that it can match and often beat the performance of the C counterpart. Having run successfully on Android devices for some time now, we can no longer call this an ‘experiment’.

It’s time to move on, yank the C code, and focus all new features and optimizations on the Rust driver.

Long live the new Rust Binder king!”

The phrase doing the work in that message is “without tripping over vulnerabilities.” That is a maintainer describing a codebase where adding a feature reliably introduced a security bug, and saying so in a public commit message.

Why Binder was the hard case

Binder is not a peripheral driver. It is the message bus for the entire Android userspace: every app talking to every system service goes through it. It handles reference counting across process boundaries, passes file descriptors between processes, manages a shared memory pool, and does all of it in a hot path on billions of devices.

Cross-process reference counting is also close to the worst possible thing to hand-manage in C. Getting it wrong produces a use-after-free, and a use-after-free in the mechanism that mediates privilege boundaries on a phone is precisely the bug class Android attackers have historically gone looking for.

It is the strongest possible argument for memory-safe kernel code, which is presumably why it was picked as an early real target rather than a toy.

The bar it had to clear

The removal is notable for how conservative the path to it was:

1. Rust Binder was written over roughly two years, largely by Alice Ryhl
2. It reached full feature parity, not a subset
3. It matched and frequently beat the C driver on performance
4. It was upstreamed in Linux 6.18 and shipped on real Android devices
5. Only then was the C code proposed for deletion

That ordering matters, because the usual objection to Rust in the kernel is that it is enthusiasm rather than engineering. Here the C code is being removed after the replacement demonstrably ran in production on a very large fleet. The performance point is the one that closes the argument: the standard rebuttal has always been that safety costs speed, and in this case it did not.

What it signals

Nothing about your desktop changes. Binder is Android, and unless you run Android containers via Waydroid or similar, you do not touch it.

What changes is the precedent. Up to now the kernel’s Rust story could be summarised as additive: new drivers in Rust, existing C untouched. A mainline C driver being retired because the Rust one is better is a different category of event, and it establishes the conditions under which that can happen: parity, performance, production proof, and a maintainer willing to say the C version has become a liability.

It lands the same week Ubuntu completed its Rust coreutils transition, and alongside Canonical funding C-to-Rust translation research and NVIDIA shipping CUDA Rust. The userspace and kernel threads are moving at the same time, which is new.

The counter-argument has not gone away and is worth stating fairly: Rust in the kernel adds a second toolchain, narrows the pool of people who can review a given subsystem, and makes the build depend on a compiler with a much shorter track record than GCC. Those are real costs. Binder is the first case where a maintainer has weighed them against the C code’s own maintenance burden and concluded the C code was the more expensive option.

# if you are curious whether binder is even present
ls /dev/binder* 2>/dev/null || echo "no binder devices"
grep -i binder /proc/filesystems

Timing

Linux 7.4 opens after 7.3 ships in October. The removal is queued in -next now, which in practice means it is happening barring something unexpected during the merge window.