Rust in the Engine Room: Measuring the Real Cost and Benefit of Memory-Safe Code in Linux's Core

For decades, C has been the uncontested foundation of Linux infrastructure. It is the language of the kernel, of systemd, of virtually every performance-critical daemon that keeps production systems alive. That dominance is now under genuine pressure. Rust—Mozilla's memory-safe systems language—has crossed from enthusiast novelty into the kernel tree itself, and its footprint is expanding faster than most infrastructure engineers anticipated. The question worth asking in 2024 is not whether Rust belongs in Linux infrastructure, but whether the tradeoffs pencil out for teams responsible for real workloads.

This piece does not argue ideology. It examines what is actually shipping, what the benchmark data shows, and what maintainers and distro packagers have learned from early adoption.

What Is Actually Shipping Today

The most significant milestone came in late 2022 when the Linux kernel merged initial Rust support in version 6.1. As of kernel 6.8, the in-tree Rust code remains modest in scope—primarily infrastructure scaffolding and a handful of driver abstractions—but the trajectory is clear. The Apple M1/M2 GPU driver effort (Asahi Linux) is among the most visible real-world Rust driver projects, and its developers have been candid about both the advantages and the learning curve involved.

Outside the kernel, the systemd project has begun integrating components written in Rust. systemd-sysext and experimental work on credential management utilities represent the project's cautious but deliberate move toward Rust for new code. Lennart Poettering and other maintainers have stated publicly that Rust is the preferred language for new systemd components going forward, while the existing C codebase will not be wholesale rewritten.

On the userland side, tools like ripgrep, fd, bat, and exa have already demonstrated that Rust can compete with or exceed C equivalents in daily developer tooling. More relevant to infrastructure teams, projects such as rustls (a TLS library), sudo-rs (a memory-safe sudo rewrite), and uutils (a coreutils reimplementation) are moving from proof-of-concept into production consideration.

The Performance Question

Skeptics of any C replacement immediately raise performance. The concern is legitimate—C's decades of compiler optimization maturity and its near-zero abstraction overhead set a high bar. The honest benchmark picture is more nuanced than either camp typically acknowledges.

In microbenchmarks measuring raw throughput for tasks like file I/O, string manipulation, and network packet processing, Rust implementations frequently land within two to five percent of equivalent C code. In some cases—particularly where Rust's ownership model eliminates defensive copying that C code performs for safety—Rust edges ahead. The uutils coreutils suite, for instance, shows cat and wc implementations that match GNU coreutils throughput on large files when both are compiled with equivalent optimization flags.

Where Rust demonstrably lags is in compile times. A mid-sized Rust project can take three to five times longer to compile than a comparable C project. For kernel module development cycles, this is a real friction point. Kernel developers accustomed to sub-second incremental builds are encountering multi-minute Rust compilation times, and this has been an explicit complaint in LKML discussions. The Rust-for-Linux team is actively working on reducing this overhead, but it remains a genuine adoption barrier in 2024.

Memory overhead at runtime is comparable to C for most workloads. Rust does not carry a garbage collector, so there is no GC pause penalty—a critical property for latency-sensitive infrastructure.

The Memory Safety Dividend

The core argument for Rust is not performance—it is correctness. Microsoft's Security Response Center has repeatedly cited that roughly 70 percent of its CVEs stem from memory safety issues. The Linux kernel, despite rigorous review processes, is not immune. A 2019 analysis of kernel CVEs found that use-after-free, buffer overflows, and similar memory errors account for a substantial share of exploitable vulnerabilities.

Rust's ownership and borrow checker eliminate entire categories of these bugs at compile time. There is no runtime cost to this guarantee—the checks happen before the binary is produced. For infrastructure teams managing systems with long uptimes and high attack surface exposure, this is not a theoretical benefit. The sudo-rs project, developed by Ferrous Systems and the Internet Security Research Group, was specifically motivated by the historical CVE record of the original sudo codebase.

Early distro packagers report that Rust components, once past the compilation stage, tend to produce fewer post-deployment bug reports related to memory corruption. This is anecdotal but consistent across multiple teams that participated in background conversations for this piece.

Adoption Barriers Beyond Compile Times

Compile speed is only one friction point. The Rust ecosystem's dependency management model—centered on Cargo and crates.io—introduces challenges for Linux distribution maintainers accustomed to tight control over vendored dependencies. Distros like Debian and Fedora have had to develop new packaging policies to handle Rust's crate dependency trees, which can number in the hundreds for a single application.

Fedora has been among the more aggressive adopters, shipping Rust-written tools as default replacements in some cases and maintaining active Rust packaging guidelines. Debian's approach has been more conservative, with ongoing debate in the project about how to handle crate vendoring versus system library linking.

Staffing is a subtler barrier. C expertise is abundant in the systems programming talent pool. Rust expertise, while growing rapidly, is still less common among the mid-career infrastructure engineers who maintain production Linux systems. Teams considering rewrites or new Rust components should budget for a meaningful ramp-up period—most experienced C developers report needing four to eight weeks before becoming productive with Rust's ownership model.

Rewrite vs. Incremental Adoption

The maintainer consensus that emerged from conversations with kernel contributors and distro packagers is consistent: wholesale rewrites of mature C codebases are rarely justified on a pure cost-benefit basis. The risk of introducing new bugs during translation, combined with the loss of decades of implicit institutional knowledge embedded in C code, makes big-bang rewrites a difficult sell.

The more defensible strategy—and the one systemd and the kernel project are both pursuing—is greenfield Rust for new components, with incremental Rust adoption in existing codebases where high-risk modules (memory management, parsing untrusted input, network handling) can be isolated and rewritten with clear interfaces to the surrounding C code.

This hybrid approach is already visible in production. Amazon's Firecracker VMM, written entirely in Rust, powers AWS Lambda. The Bottlerocket container-optimized OS from Amazon uses Rust extensively for its update system and host agent. These are not experiments—they are handling production traffic at significant scale.

The Verdict for Infrastructure Teams

Rust is not displacing C in Linux infrastructure on any short timeline. The kernel will remain predominantly C for the foreseeable future, and the existing userland ecosystem is not going to be rewritten wholesale. What is changing is the default choice for new infrastructure code, and that shift carries real implications.

For teams evaluating whether to adopt Rust in their own infrastructure tooling or to contribute to Rust-based open-source projects, the calculus looks like this: the memory safety guarantees are real and measurable in CVE reduction terms, runtime performance is competitive, and the primary costs are compile-time overhead and workforce upskilling. For security-sensitive components handling untrusted input or managing privileged operations, those costs are increasingly easy to justify.

For performance-critical hot paths where C expertise is deep and the codebase is stable, the case for migration remains weak. Rust's strongest argument is not that it is faster than C—it is that it makes certain categories of catastrophic failure structurally impossible. In production infrastructure, that guarantee has a dollar value that is finally becoming legible.