Rust Binder parity makes C removal a real choice

The argument has shifted. It is no longer whether Rust can ship in the kernel. It is whether a Rust implementation that has reached feature parity, production Android use, and competitive performance should replace its C counterpart outright, ending dual maintenance in a driver that has spent years accumulating complexity and vulnerabilities.

Carlos Llamas put that question on the table with a blunt proposal: remove the long-standing C Binder IPC driver and keep only the Rust version. "The day has finally come," he wrote. "We are dropping the legacy C implementation of the Binder IPC driver in favor of its Rust version." His case is maintenance fatigue as much as language preference. "For 15+ years, the C driver has grown increasingly complex, making it incredibly painful to maintain and land new features without tripping over vulnerabilities." Alice Ryhl's Rust Binder, he argued, is past the trial stage. It has full feature parity, can match and often beat the C path on performance, and has already run on Android devices. "Having run successfully on Android devices for some time now, we can no longer call this an "experiment"." The patch carries her acknowledgment. The rhetoric does not hedge: "Long live the new Rust Binder king!"

That removal bid lands beside two other threads that make the same underlying pressure concrete. Alistair Francis has posted a sizable Rust SPDM requester stack for kernel-side device authentication and attestation. SPDM rides transports such as PCIe and related channels. From the kernel's threat model a device stays untrusted until verification succeeds, so the code must parse untrusted responses against a specification that runs to roughly two hundred pages in 1.2.1 and nearly two hundred fifty in 1.3.0. "As such we have the kernel parsing untrusted responses from a complex specification, which sounds like a possible exploit vector. This is the type of place where Rust excels!" Francis aims for the smallest upstreamable requester first: enough to complete a conversation and report authenticated status to userspace, without yet handing full evidence and certificates upward, accepting userspace nonces, or taking on post-quantum and other advanced options. Supporting C pieces from earlier work appear only where required; the series stands alone.

Review is proceeding in the ordinary, careful way. Jonathan Cameron has been walking the patches "as a non rust person," giving Reviewed-by tags on digest and certificate-chain pieces while flagging where signature generation for CHALLENGE was hard to line up with the specification, and asking for at least one concrete example of which non-obvious device types would use a renamed host-side TSM helper beyond the root-complex integrated endpoint Francis has in mind. Francis is folding fixes, adding comments around the crypto flow, and hoping for more Rust-fluent review on lifetimes and state machines. The technical substance is exactly the kind of state-heavy, untrusted-input protocol work that dual-language maintenance would punish twice over if a C parallel were kept forever.

At the same time, memory-management work is removing a structural reason Binder (and networking) code stayed awkward. Suren Baghdasaryan, continuing a series begun by Dave Hansen, makes per-VMA locks unconditional across configs rather than limiting them to selected architectures with SMP and MMU. The primitives underneath (RCU, maple trees, refcounts) already work without those constraints. The cost is a slightly larger VMA and mm_struct on !SMP and !MMU builds; the gain is less ifdef complexity and the ability to use per-VMA locking in generic code without mmap_lock fallbacks. "Binder and networking folks: Your code is the target of the cleanups," the cover letter says plainly. A new helper that no longer requires a fallback path makes the locking model easier to call correctly. Andrew Morton has the pile in testing.

The Binder interaction with that series is itself a miniature of why single implementation matters. Automated review raised possible page-lifetime issues around mremap and VM_MIXEDMAP insertions. Alice Ryhl replied that "The binder bug is not actually a bug": vm_insert_page takes a refcount, so freeing without an explicit removal is not a use-after-free. Carlos Llamas agreed on the UAF point yet still wants mremap rejected so pages are not left unreachable to the shrinker and unusable to Binder. Liam R. Howlett sharpened the geometry: after a same-size mremap the PTE moves, the old VMA closes, and the page is effectively misplaced rather than pinned. David Hildenbrand noted that NOMMU support and related cleanups could have been staged more narrowly. None of this is glamorous, but it is the locking and lifetime detail that becomes harder when two Binder implementations must stay aligned.

The through-line is practical, not philosophical. Rust Binder at Android parity invites deletion of the C driver so features and fixes land once. Rust SPDM puts a memory-safe language on a parser for untrusted, specification-heavy device responses. Unconditional VMA locks simplify the Binder paths that remain and remove a reason to keep conditional fallbacks. Together they challenge the quiet default that Rust stays forever optional and that C originals remain for every security-sensitive user.

The counter-pressure is equally concrete. Deleting the C Binder makes Rust a hard dependency for that IPC path; trees or configs that do not build Rust lose the driver unless policy preserves an escape that the posted removal does not emphasize. SPDM still needs domain review from people who may not write Rust daily, and Cameron's experience shows how quickly protocol alignment questions dominate language questions. Performance and behavioral parity claims will be re-checked by shippers who cannot absorb Binder regressions. The VMA series reduces ifdef debt but does not by itself decide whether C Binder should vanish.

For now the removal patch is proposed and acknowledged by the Rust Binder author, with Greg Kroah-Hartman already on the thread. The SPDM series is in v3, gathering incremental review while cryptographic and lifetime comments are addressed. The VMA-lock work is in -mm with Binder follow-ups likely on mremap policy. What is unresolved is the policy threshold: whether production use plus parity is enough to end dual maintenance in a widely deployed, vulnerability-sensitive driver, or whether the kernel will keep paying for two implementations until a broader rule says otherwise. Binder is the first place that choice is no longer theoretical.