Linux is replacing the C implementation of the Android Binder driver with Rust. This shows that memory safety is becoming a practical engineering choice.

For more than 15 years, Android's Binder driver has helped apps and system services talk to each other. Users may never see this component, but many operations depend on it. When an Android app requests a service from the operating system, Binder handles the inter-process communication.

For most of that history, the driver was written in C.

Now Rust is here.

The Linux kernel is removing the old C implementation of Binder and moving to the Rust version. The change has been merged into the Linux 7.4 development cycle, and Google plans to concentrate future Binder development on the Rust version.

This is not just another Rust driver entering the kernel. A long-used implementation is being removed because the replacement has matured enough to take over its work.

Google engineer Carlos Llamas said the old implementation became increasingly difficult to maintain as complexity grew. The Rust version, developed over several years, has achieved functional parity; in some tests, it reportedly matches or exceeds the C implementation's performance.

Is C outdated? No. But Rust is taking over an important and widely used system component, which shows Rust is ready for the table.

What is Binder

Android apps do not run alone. An app may need to communicate with system services to get information, use hardware features, or perform operations that require higher privileges.

These processes usually have separate address spaces. One process cannot directly access another process's memory or call functions as if they were in the same program.

They need a controlled communication mechanism. That is the problem inter-process communication, or IPC, solves.

Binder is one of Android's core IPC mechanisms. The Binder driver works with libraries and services in Android user space to carry out transactional communication between processes.

The simplified flow looks roughly like this:

Android application
        |
        v
Android framework / IPC interface
        |
        v
Binder driver in the Linux kernel
        |
        v
Target system service

This is a conceptual diagram and does not fully show the detailed steps of every Binder transaction.

Binder sits between user-space apps and a kernel-managed communication mechanism. It has to handle complex operations like transactions, process state, threads, references, and memory.

If such a component has defects, the consequences can be serious. Over the years, Binder has had multiple security issues fixed around memory management and transaction handling, so maintainability is also a major concern.

So replacing it is not just about rewriting it in another language. The new implementation must preserve behavior that Android software depends on.

Why remove the C implementation

C has been an important language in OS development because it gives direct control over memory and low-level resources.

But that control comes with risk.

When using C, developers must carefully manage pointers, object lifetimes, memory allocation, and buffer bounds. Mistakes can lead to memory corruption, use-after-free vulnerabilities, or crashes.

Binder's complexity makes this especially difficult. Over the years, the driver has evolved to meet Android's growing demands. Interactions between features make it harder for developers to predict what a change will affect.

In the removal patch submitted in September 2026, Google engineer Carlos Llamas explained that maintaining the C driver was becoming increasingly burdensome, and adding new features without introducing bugs was difficult.

This does not mean all C implementations are unsafe, nor that rewriting in Rust automatically eliminates all security vulnerabilities.

This change, plainly speaking, is because Rust provides language-level protections that can prevent many memory safety errors in safe Rust code.

These protections reduce the dangerous states developers must handle manually. You can simply think of it as: for rules the compiler can check, programmers are not trustworthy; the compiler is.

To meet the needs of low-level systems programming, Rust still allows explicitly marked unsafe operations. Logic errors, incorrect permission checks, race conditions, and other design problems can still exist.

The advantage of the new driver is not that it will never have problems, but that certain types of errors are much harder to introduce from the start.

For a driver at the heart of Android inter-process communication, that advantage is concrete.

First it has to be a viable replacement

Writing a new implementation in Rust is only the beginning.

The new driver needs to support the features Android depends on, behave correctly under real workloads, and perform well enough to replace the original.

It also has to meet the practical requirements of kernel development: code review, testing, bug fixes, compatibility, and integration with the rest of the Linux kernel.

The Rust Binder driver took several years to develop, with Alice Ryhl as one of its main contributors. It was merged into the Linux mainline kernel before the C implementation was retired.

The important milestone here is functional parity.

Functional parity means the new implementation supports the relevant capabilities of the old one that must be preserved. Without it, removing the original driver could strip the system of features it depends on.

The project also reported competitive performance. According to the removal announcement, in tests the Rust Binder can match the C implementation's performance, sometimes even being faster. This shows that in the relevant tests the Rust version is competitive with C, but it does not justify claiming Rust is faster than C in all situations.

Performance depends on workload, the specific implementation, compiler, configuration, and measurement methods.

The more grounded conclusion is that the Rust implementation is mature enough that maintainers no longer need to treat it as an experimental alternative.

What exactly changed in the Linux kernel

A removal patch named binder: rm -f binder.c deletes the old C implementation and adjusts the relevant kernel build configuration to use the Rust version.

The patch removes more than 7,000 lines from drivers/android/binder.c. According to the patch discussion, the entire change touches 20 files and deletes 11,470 lines.

This change lets the project avoid maintaining so much old code in parallel with the Rust implementation.

But the number of lines deleted is not a direct measure of security or code quality improvements. The more important architectural change is that the project no longer needs to maintain two separate implementations of the same driver.

Parallel maintenance brings extra work: bugs may need fixing twice, new features can diverge, and tests must cover differences between two versions.

With only one implementation left, future Binder development can concentrate on a single codebase.

Why Rust is needed

Kernel code is different from ordinary application code.

A desktop app may just need a restart after a crash. A serious kernel fault can affect the entire operating system. Security vulnerabilities in kernel drivers can also give attackers privileges they did not have.

Binder is especially important because it assists Android process communication, and these processes may have different privilege levels.

Consider a simplified example.

Suppose a driver tracks an object used by multiple processes. One operation frees the object, while another still thinks it exists.

If the implementation does not correctly handle the object's lifetime, the second operation can access memory that is no longer valid.

In C, preventing such use-after-free problems requires careful manual management of lifetimes and synchronization.

Rust's ownership and borrowing rules can stop many operations that violate memory lifetime constraints in safe code. Its type system can also express certain relationships explicitly, so developers do not have to rely solely on discipline.

This does not solve all kernel security problems. Drivers still need correct synchronization, validation, access control, and handling of untrusted input. unsafe code still needs careful review.

But preventing certain types of memory errors at compile time does reduce the burden on developers and reviewers.

Binder's practice shows these protections can be used in real, performance-sensitive kernel code, not just small demo programs.

Will Android become a Rust-based system?

No.

This change targets Binder. Android still relies on large amounts of C and C++ code, and the Linux kernel itself remains a multi-language project.

Rust's role in the kernel is expanding, but that does not mean every existing driver will be rewritten.

Each subsystem has its own requirements, maintainers, history, and constraints. Some components fit Rust well, some may not be worth rewriting.

It is also important to distinguish changes in kernel source from actual deployment on devices.

Removing the C implementation means future kernel development moves to Rust Binder. But which version a given Android device uses, and when, depends on its kernel and vendor software. This does not mean every Android phone will receive an immediate update.

Linux kernel maintainer Greg Kroah-Hartman welcomed the removal in the patch discussion. In a subsequent char/misc pull request, he said the Rust version is stable and will be used on 'billions of devices'. That statement reflects Binder's huge deployment footprint, not that all those devices have switched at once.

What to learn

Do not pick Rust just because you have the chance. Evaluate whether a language change is worthwhile for the specific engineering problem.

Binder's replacement implementation had to meet several requirements:

• Correctness: preserve the features apps and system services depend on.
• Security: reduce the risk of certain types of memory safety errors.
• Performance: stay competitive under relevant workloads.
• Maintainability: make future changes easier to implement and review.
• Compatibility: integrate with the existing kernel and Android infrastructure.

The Rust implementation became a viable replacement because the project took time to meet these requirements step by step.

Compared with language popularity rankings or predictions about the future, this kind of practice is more convincing.

If you are also considering bringing Rust into your own project, you can follow the same principle: first identify the real source of risk or maintenance cost, then define which features the new implementation must preserve. Test the replacement against these requirements before removing old code.

Rewriting is not automatically an improvement. A successful replacement has to prove its value.

Rust is taking the next step

Early discussion about bringing Rust into the Linux kernel often centered on one question: can this language even be integrated?

That was an important first step. Kernel developers needed the infrastructure, abstractions, and rules to let Rust code coexist with existing C code.

But adding a new language is one thing; proving it can replace a mature implementation is another.

Binder is a more concrete milestone: the replacement has achieved functional parity, is already in use on Android devices, and is now the focus of future development.

What supports this decision is prior engineering practice. Before the old implementation was retired, the Rust version went through development, testing, maintenance, and comparison with the existing driver.

This does not prove every kernel subsystem should go the same route. But it shows that for at least one important subsystem, Rust has become a viable choice to replace the ongoing maintenance of a complex C implementation.

C will not disappear from Linux. Rust is not a universal solution to software security problems. A successful migration does not guarantee future migrations will succeed.

But this decision on Binder shows Rust's role in systems programming has moved beyond the experimental stage.

It shows developers trust a Rust implementation enough to stop developing the C version that has been around for years.

If anyone still says Rust is all talk, I will show them this article first.