Rust Binder replaces the C binder driver in the Linux kernel

In the 2026 edition of the Kangrejos conference, Carlos Llamas announced the deletion of the C implementation of the Binder driver (binder.c) in Android. Much applause. The Rust implementation, developed by Alice Ryhl and others over a few years, takes its place. The original source for this post is the talk report on LWN (30 October 2026), with the upstream patch set which deletes drivers/android/binder.c as secondary source.

The Binder driver is the inter process communication system used for basically everything in Android. Every app and system service talking to each other, every app and kernel talking to each other, every IPC across processes. The new implementation language is not a cosmetic change. It's one of the most significant milestones yet for Rust in Linux. And it was accomplished in a seemingly inconspicuous way: by deletion.

What Binder is and why it matters

The Binder is the RPC system in Android. When an Android app wants to get the location, a sensor reading, a permission check, a graphics buffer, etc., that's what crosses process boundaries in the form of Binder transactions. The Binder driver is a kernel driver that mediates the transactions, manages object refs, handles death notifications, enforces security policy, etc. Almost all relevant actions on an Android device involve it.

This makes Binder a prime candidate for Rust for years. A memory safety bug in a driver that all apps and all system services rely on is not a corner case. It's a systemic risk. The C implementation was mature. It was tested extensively. But it was also large and complex. It had a lot of manual lifetime management and lock discipline, which is hard to audit in a kernel C implementation. The goal of the Rust implementation was to take advantage of the compiler to help with this.

What the deletion means

The importance of deleting binder.c is that now there's only one implementation. For many years there was a Rust implementation of Binder and a C implementation. The C implementation was the reference. The Rust implementation was an experiment. There are costs to that: double bug fixes, differences in behaviour in edge cases, and the constant question of which is the authoritative implementation.

With only one implementation, those costs are gone. But that's not all. There's no escape. Previously if there was a bug in the Rust version, you could work around it by falling back to the C version. Now there's only the Rust version. So the only bugs are the bugs in the Rust version. That's a strong statement of confidence. But it's the kind of statement you only make when the maintainers are confident that the Rust version is at least as correct and at least as fast as the original.

The hard parts, per the Kangrejos talks

The LWN report on the talks mentions some areas that proved challenging. These are important to understand because they're indicative of the kinds of problems that you'll run into in any large Rust in Linux port.

• Reference counting and object lifetimes: Binder is built around reference counted kernel objects (nodes, refs, buffers). There are complex rules about when references are acquired and released across transactions. In C this is all done manually. As usual, this tends to leave subtle bugs in the error cases. In Rust you can express much of this at the type level. But mapping the existing concurrency model to Rust rules without changing behaviour was tricky. The goal wasn't to redesign Binder. It was to express the existing design in a language that can check it.

• Locking: The Binder has a non trivial locking scheme. There are nested locks and ordering constraints. This has been developed over years of C kernel work. To port this to Rust, you could try to reproduce it exactly (including lock ordering) or redesign it. Redesigning it could potentially change timing and behaviour. Reproducing it exactly could potentially leave the complexity in place. The talks mentioned how this was worked through. It's the kind of pragmatic compromise that's typical of successful ports. Preserve the design. Make the invariants explicit. Use the compiler to check them.

• FFI and abstraction boundary: Even with binder.c gone, Binder remains at the boundary between the Rust code and the rest of the C kernel. It calls C subsystems. It exposes interfaces that C callers use. It's involved in the kernel memory management and scheduling. So in the Rust side you need to define safe wrappers for these interactions. The quality of the wrappers will determine whether the safety benefits are real or simply moved somewhere else. This is the unglamorous part of any Rust port. It's the area with the most risk.

• Performance: It's a driver that all Android transactions flow through. There can't be a regression. The talks mentioned that performance was a constraint throughout. That the Rust version had to be at least as good as or better than the C version on relevant benchmarks before deletion was justified. This is the appropriate bar. And meeting it makes it more than just an experiment.

Why this matters beyond Android

The Binder is the most prominent deletion of C in favor of Rust in the kernel yet. It sets a template. The lessons -- how to port a large, stateful, concurrency-heavy driver without changing the observable behaviour, how to deal with the FFI boundary, how to meet performance requirements -- can be applied to other drivers and subsystems. The Rust for Linux project has been making the case for all this for years. Binder is the biggest piece of evidence yet that it's possible. And that it can be done in a way that's acceptable to the kernel community.

It also changes the default answer to "should this new driver be written in Rust?" For many years the answer has been, "you can but you'll be maintaining two implementations and fighting with the community." Now that binder.c is gone and the Rust version is the authoritative one, for new self-contained drivers, the answer is increasingly "yes. But you won't be alone." This is a cultural change as much as a technical change. And it's the kind of change that only happens after a high profile success.

The porting strategy: behaviour preservation over redesign

The most important decision in the Binder port was what not to change. The goal of the Rust version was to try to reproduce the behaviour of the C version as closely as possible. Not to redesign Binder. That's reflected in the result. When binder.c was deleted, there was no changelog with new features or changes in behaviour. There was a changelog with code deleted.

But there are costs to that. It means leaving design decisions in place that were made for C. That might not be idiomatic in Rust. It means some of the safety benefits that could be provided by Rust in principle are limited because you need to match existing behaviour. It means the port is less useful as a demonstration of what can be done with Rust because it's not showing off deliberately.

But that has the upside that it's reviewable and acceptable. If it had been a redesign you'd have to get the kernel community to revalidate the behaviour of a driver that everything relies on. That's a much bigger ask than "here's the same driver but in a different language". So preserving the behaviour is the price of admission for a port of this size. And meeting it is what got the deletion merged.

It's something to keep in mind for anyone thinking about doing a similar port. It's tempting to take the rewrite opportunity to fix all the things that are wrong with the original. But that's not a good idea for a driver that's this central. Fix the language. Preserve the behaviour. Improve incrementally once you've got only the new implementation.

How the community reviewed it

Large Rust ports in the kernel don't get merged because they're in Rust. They get merged because they're reviewed. And reviewing Rust code in the kernel is a skill that's still being developed. The Binder port was helped by having maintainers who were comfortable in both C and Rust. And by having a review process that treated the Rust code with the same level of scrutiny as the C.

But that's not the norm yet. Many kernel subsystems don't have a Rust reviewer. And if you land a port in one of those, the bar is higher. You have to be reviewed by people who might not be fluent in Rust. So the code needs to be clearer and better documented than it would otherwise be. Binder established a standard for what that review looks like. Future ports will be measured against that.

What is not settled

It's easy to think it's the end of the story. But there's still a few open questions.

• Correctness under real world load. Just passing the tests and meeting the benchmarks isn't the same as surviving the long tail of Android usage on thousands of different device models and kernel versions. The Rust version is going to get exercised by the whole Android ecosystem over the next few years. Bugs will show up. The question is: are they caught early and fixed cleanly? And do the safety properties of the Rust code make them less severe when they do show up?Maintenance overhead. It's easier to maintain just one implementation, but now it's just the rust version and maintainers are responsible for the whole thing. Linux kernel community is still building up capacity to review Rust code, have tools, debuggers etc. Binder is a huge and complicated thing to maintain, especially in a language that isn't necessarily a first language for many kernel developers.

Abstraction layer. Safe wrappers that Binder uses are shared infrastructure. It's not just Binder that gets affected by quality of those wrappers. It's all Rust drivers. There is an ongoing effort to get them right. And Binder requirements will continue to drive improvements in kernel Rust support for a while.

Conclusion

Deleting binder.c is a small commit, but a commit with huge consequences. It's a commit that replaces a well established C implementation with a Rust one that maintainers think is at least as good. And it does it in one of the most central and most used drivers in the Android stack. Huge step for Rust in linux kernel. It's a data point that will be used in all future discussions about porting a driver or not.

There are open questions. But they're the right kind of open questions. Not "is it even possible to port", but "how does it work under the load". Much better place to be than linux kernel community was a few years ago when we had a question "should rust be in the kernel at all".

Sources

• LWN, "Removing binder.c" (30 Oct 2026): https://lwn.net/Articles/1102982/
• Linux kernel source, drivers/android/ (Binder driver): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/android
• Rust for Linux documentation: https://rust-for-linux.com/
• Kangrejos 2026 conference: https://kangrejos.com/

← back to posts