Android Binder Proposal Makes Rust Required for Linux Builds

Phoronix first reported the planned retirement on September 18. The primary kernel mailing-list patch, posted by Google engineer Carlos Llamas on September 12, confirms the core facts and reveals a more consequential implementation detail than the headline suggests: this is not merely deleting binder.c. The patch removes 11,470 lines across 20 files, changes the standard Binder configuration symbol to depend on RUST, and repoints the normal binder module name at the Rust implementation.

Greg Kroah-Hartman, the Linux stable maintainer who oversees the char/misc tree, replied that he would queue the patch after catching up on pending Binder fixes. That makes the change a serious candidate for the Linux 7.4 merge window, but not a completed upstream merger as of Friday, September 18, 2026.

Binder’s replacement is moving out of parallel mode​

Binder is Android’s kernel-level inter-process communication mechanism. Android uses it for application and service calls, and its security model relies heavily on separating apps, processes, and system services. The Rust for Linux project describes Binder as one of Android’s most security- and performance-critical components, because most IPC on Android passes through it.

Google began publicly pursuing the Rust rewrite in 2023. At that stage, the stated goal was to preserve Binder’s external behavior while making ownership, reference counting, locking, bounds handling, and error paths easier to reason about. The original C driver had accumulated a substantial set of intertwined lifetime and locking rules over roughly 15 years.

The replacement entered mainline in Linux 6.18-rc1, but initially existed alongside the C implementation. That dual-track arrangement gave Android maintainers a way to exercise the new driver on real devices while retaining the familiar C path. The new removal patch says that period is over: Llamas states that the Rust code has full feature parity, has been running on Android devices for some time, and can match or sometimes exceed the C driver’s performance.

The key operational outcome is that Google intends to send all new features and optimization work to one implementation. Maintaining both versions would otherwise mean duplicating behavior, testing, bug fixes, and security review for an interface that Android cannot readily replace.

The configuration change is the part kernel builders need to notice​

The proposed patch removes the separate CONFIG_ANDROID_BINDER_IPC_RUST option. In its place, the longstanding CONFIG_ANDROID_BINDER_IPC option gains a direct depends on RUST condition.

That is a deliberate compatibility break for kernel builders, even though it should be invisible to ordinary Android users. A kernel configuration that enables Binder but lacks a usable Rust build environment will no longer be able to select Binder at all if the patch lands unchanged. Previously, an integrator could build the traditional C driver with CONFIG_ANDROID_BINDER_IPC, or choose the Rust version through a distinct option.

The patch also changes the module identity from rust_binder to binder. That avoids exposing the language transition as a permanent product-facing distinction, and it means scripts or monitoring rules that look specifically for a rust_binder module should be reviewed. The intended end state is clear: Rust is no longer a test implementation with a differently named module; it becomes Android Binder.

For teams maintaining custom Android kernels, the immediate checklist is short:

• Ensure the kernel build system provides the supported Rust compiler, bindgen requirements, and related tooling needed by the target kernel branch.
• Review defconfigs and build automation that refer to CONFIG_ANDROID_BINDER_IPC_RUST, because the symbol is being removed.
• Update validation and diagnostics that expect the Rust driver to register as rust_binder, since the replacement module is named binder.
• Retest Binderfs-dependent container, emulator, and multi-instance Android configurations rather than assuming a source-compatible transition guarantees identical operational behavior.

The patch removes the old C Binderfs source and changes the Rust-side Binderfs wrapper, so Binderfs is included in the consolidation rather than left as a C exception. It also removes the standalone C Binder allocator KUnit tests. That last deletion deserves scrutiny during review: fewer source files do not automatically mean equivalent regression coverage, particularly in memory allocation and lifecycle handling.

Production use supports the proposal, but it does not make Rust infallible​

Google’s argument is not that Rust makes Binder bug-free. It is that Rust makes a particular category of low-level defects harder to introduce and makes a long-lived, complex driver easier to evolve. That is an important distinction for security teams.

The record already shows that Rust Binder has had security fixes. CVE-2025-68260 addressed a race condition involving a Binder death-notification list and an unsafe list operation. NVD’s description documents a crash arising from the issue, while the Linux CVE record identifies the problematic concurrent list manipulation. Other 2026 Linux CVEs have covered Rust Binder correctness issues, including notification locking and a zero-length file-descriptor-array case.

Those advisories are not evidence that the rewrite failed. They are evidence that memory safety is only one dimension of kernel correctness. Rust can constrain use-after-free, data-race, ownership, and bounds mistakes where code remains in safe Rust, but Binder still has concurrent state, IPC protocol semantics, kernel callbacks, and necessary unsafe boundaries. Review of synchronization, authorization, resource exhaustion, and logic flaws remains necessary.

The more defensible reading of Google’s move is that it reduces the cost of maintaining a security-sensitive subsystem with complicated object lifetimes. It does not grant a blanket security guarantee, nor does it let Android vendors relax kernel patch management. Devices and custom kernels running Rust Binder must still consume the relevant upstream fixes.

What this means for Windows-based Android development​

This is not a Windows kernel change, and it will not alter everyday Windows 11 PCs. Microsoft’s Windows Subsystem for Linux can, however, be part of an Android platform build workflow, while Android Studio developers and device makers often operate from Windows workstations even when compilation and CI run in Linux environments.

For that audience, the important impact is upstream dependency management. A Windows-hosted development workflow that produces Android Common Kernel derivatives, Generic Kernel Image variants, or device-specific kernels will need a Rust-capable Linux build environment once it takes a kernel version containing this change. The shift could surface late in CI if an organization has treated Rust support as optional because it did not compile Rust drivers.

Google’s Android Common Kernel repository provides evidence that this is already more than a theoretical upstream experiment. Its September 2026 Android 17 kernel release includes Rust Binder updates, including additional dynamic debug support for dead transactions, failed acknowledgments, and process-death-related cleanup paths. That does not prove every Android device has switched to the Rust path, but it corroborates the claim that Google is actively maintaining and shipping the driver in its Android kernel work.

The sharp line is between application developers and platform developers. An organization packaging APKs, managing Android devices through an EMM platform, or running standard Android Studio workflows will not need to change its applications because Linux replaces Binder’s internal implementation. A team compiling kernels, debugging Binder transactions, carrying vendor patches, or supporting Android-derived platforms will.

Linux 7.4 is the decision point, not the finish line​

Kroah-Hartman’s response makes the removal likely to enter the char/misc development queue, and Phoronix reports that it is aimed at Linux 7.4. But a queued patch is still subject to the normal upstream process: it can change in review, be deferred, or expose failures on configurations not represented by Google’s Android deployment.

The submitted patch is nonetheless unusually explicit about the maintenance decision. It removes the parallel configuration, deletes the legacy implementation and test code, and assigns the canonical Binder module name to Rust. That is stronger than adding another Rust driver beside a C predecessor.

If it lands, future Binder maintenance will happen in Rust, and the tooling requirement moves with it. For Android kernel teams working from Windows, Linux, or CI systems in between, the consequence is concrete: treat Rust support as a required part of the Android kernel toolchain before adopting the Linux 7.4-era Binder changes.