BUS1 In-Kernel IPC Rewritten in Rust, Posted for Linux Community Review

David Rheinsberg, one of BUS1's original developers, posted a 16-patch, roughly 9,000-line Rust rewrite of BUS1 to the Rust-For-Linux mailing list, reviving a capability-based IPC proposal that never made it into the mainline Linux kernel in its original C form. Michael Larabel at Phoronix flagged it as "a big surprise," and given the decade-long backstory, that framing holds up.

To understand why this matters, it helps to know what capability-based IPC actually means. Traditional Linux IPC, whether pipes, UNIX sockets, or Netlink, relies on kernel-enforced namespaces and user/group identity for access control. D-Bus, the dominant IPC layer for Linux desktops and system services, adds a userspace broker that mediates connections using well-known bus names and policy files. Capability-based IPC flips that model: instead of asking a broker for permission to talk to a service, you hold an unforgeable token representing the right to communicate directly. No broker, no global name registry, no policy lookup at runtime.

BUS1 was designed from the start around that capability model. After KDBUS failed to make it into the mainline Linux kernel more than a decade ago as an in-kernel version of D-Bus, BUS1 was proposed as a clean-sheet design for in-kernel, capability-based IPC. BUS1 didn't gain enough traction to make it to the mainline kernel, and then many of the same developers devised dbus-broker as a more performant D-Bus userspace implementation.

The Rust rewrite changes the calculus on two fronts. Rust's ownership model and borrow checker enforce memory-safety invariants at compile time that C requires developers to maintain manually. In kernel IPC code, the bugs that enforcement eliminates are exactly the dangerous ones: use-after-free, data races on shared IPC state, and double-frees in message-passing paths. The new BUS1 version was stripped down to the basics and implemented in Rust, which is a deliberate structural choice: submit the smallest reviewable surface first, rather than arriving with a complete system and triggering the review fatigue that burned previous attempts.

Where `unsafe` still lives matters too. Rust in the kernel is not zero-unsafe; any code that directly touches hardware registers, raw pointers from the kernel's C core, or FFI boundaries requires unsafe blocks. The BUS1 patches isolate those boundaries rather than spreading unsafe throughout the codebase, and that isolation is where the safety argument is strongest. Kernel reviewers will scrutinize how cleanly that safe/unsafe line is drawn, not just whether the code compiles and passes CI.

Against existing kernel IPC primitives like Netlink or io_uring's fixed-buffer model, BUS1 offers something those primitives lack: a composable, transferable capability handle that processes can pass to each other directly. Compared to D-Bus, there is no centralized name service to become a bottleneck or a single point of policy enforcement.

Even if BUS1 itself does not land in mainline, the exercise will influence how Rust is used in kernel modules and may accelerate the adoption of Rust for other critical kernel subsystems. The milestones worth watching: whether the Rust-For-Linux community review surfaces objections to the safe/unsafe boundary design; whether subsystem maintainers weigh in on the ABI and UAPI surface; and whether Rheinsberg posts a revised series incorporating that feedback within the next few patch cycles. BUS1 never landed in C despite years of effort. Whether it lands in Rust will depend less on the language and more on whether the kernel community has finally warmed to the capability IPC model itself.