Greg K-H: "Writing new code in Rust is a win for all of us"

Rust’s safety benefits and limits

• Many comments agree Rust won’t eliminate bugs but can drastically reduce classes of memory errors: UAF, double free, unchecked error paths, and many out-of-bounds accesses.
• Rust’s culture of treating even rare UB as CVEs is seen as a plus compared to C/C++, where UB is often shrugged off as “don’t do that”.
• Critiques note that:
  • Unsafe Rust can reproduce C-style bugs, and some kernel-adjacent CVEs already involve unsafe blocks.
  • Rust does not inherently fix integer-overflow, logic, or concurrency bugs.
• Some argue Rust’s advantages are oversold and that incremental hardening of C (better APIs, static analysis, sanitizers) is underplayed.

Use of Rust in the Linux kernel

• The central position: use Rust for new code, especially drivers, while the existing ~30M LOC C base remains and continues to be hardened.
• A long-time stable maintainer argues that most bugs he sees are exactly those Rust can prevent, freeing attention for “real” bugs (logic, races).
• No serious proposal to rewrite existing subsystems; focus is on making Rust first-class for new drivers.

Maintainer workload, policy, and the DMA/R4L conflict

• A key concern from some C maintainers: a mixed-language kernel increases burden, especially when core C APIs change and Rust bindings must track them.
• Policy as restated: C APIs are free to change; Rust is optional; if Rust breaks, Rust maintainers must fix or Rust code can be disabled for that release.
• Tension remains because if Rust succeeds and important drivers are in Rust, breaking Rust builds will become practically unacceptable, implying more work for C maintainers later.
• Recent mail from the project lead makes clear Rust is welcome and individual subsystem maintainers cannot veto Rust users of their APIs if their own C code isn’t touched.

Alternatives: safer C, C++, and formal methods

• Several argue that:
  • Clang’s -fbounds-safety, sanitizers, and static analyzers could remove most memory bugs in C with less upheaval, but historically such tools see limited, inconsistent use.
  • A restricted C++ subset could bring RAII, templates, and type-safe generics with existing toolchains, and would improve over macro-heavy C.
• Counterarguments:
  • C++ still leaves most memory-unsafe constructs available; “safe subsets” are unenforced and culturally fragile.
  • The C++ committee is seen as slow and conflicted on memory safety; multiple posts reference recent “safe C++” drama as evidence.
  • Formal methods tools (Frama-C, SPARK) give stronger guarantees but are far harder to use, don’t scale well to the full kernel, and lack an active community willing to do that work.

API stability and Rust bindings

• Some fear that once Rust bindings exist, kernel-internal APIs will effectively be forced to stabilize, slowing refactors and “ossifying” design.
• Others reply that:
  • Internal APIs have always been free to change; the same will remain true, with Rust bindings treated like any in-tree user.
  • Most API changes are either mechanical (easy to fix in bindings) or rare, and linux-next plus the two-phase release cycle give time to align Rust bindings.
• There’s an unresolved, implicit question: when Rust matures and Rust-only drivers become important, will policy have to evolve to treat Rust as fully first-class (i.e., C maintainers helping maintain bindings)?

Language and tooling concerns

• Objections to Rust:
  • Learning cost for veteran maintainers and cognitive load of switching between languages.
  • Mixed build systems (kbuild + rustc, possible cargo use) and slower compile times.
  • Fear that Rust’s success crowds out research into alternative safe systems languages.
• Responses:
  • Rust in-kernel uses the existing build system and calls rustc directly; no cargo for drivers.
  • Rust’s edition and stability story is described as strong; breaking language changes are rare and carefully managed.
  • Legacy architectures lacking Rust/LLVM support can continue with C-only kernels, or rely on a GCC Rust backend in future.

Kernel architecture and future directions

• A side thread discusses whether the deeper problem is the monolithic, ever-growing kernel:
  • Some see the Rust fight as a symptom that Linux has hit a complexity ceiling; they wish for microkernels (seL4, Fuchsia’s Zircon, Redox) with user-space drivers.
  • Others argue that full formal verification and microkernels aren’t realistic general-purpose replacements today, due to hardware DMA, IOMMUs, and complexity of modern userspace.
• Consensus: microkernels bring strong isolation benefits, but are not close to displacing Linux; Rust is seen as a pragmatic, here-and-now safety improvement.

Community, culture, and process

• A recurring theme is people vs technology:
  • Rust is attractive to newer contributors; sticking only with C risks aging out the maintainer base.
  • Some established C developers are perceived as resistant to learning Rust or to multi-language complexity, and feel Rust “sucks the air out of the room”.
• Several comments stress:
  • The experiment’s success hinges on relationships and documentation as much as on the language.
  • Leadership needs to resolve deadlocks; recent emails from the project lead and senior maintainer are seen as overdue but clarifying.
• Outside observers express fatigue with the drama but generally accept that the people doing the work (on both sides) will ultimately define how far Rust goes in the kernel.