For years, conversations about memory safety in core Linux infrastructure have circled around the same difficult question: how do you modernize critical system software without rewriting everything from scratch? On October 24, 2026, the systemd project took a concrete step toward answering that question.
The project merged support for writing new programs in Rust. The change, submitted by Christian Brauner and landed in the main development branch, makes it possible to build certain systemd components in Rust alongside the existing C codebase. The first practical user of this infrastructure is a new tool called systemd-keyring-setup, which handles keyring provisioning and certificate enrollment during early boot.
This is not a rewrite of systemd in Rust. It is a carefully limited, deliberate opening of the door. And for that reason, it is one of the more meaningful infrastructure changes in the Linux userspace stack this year.
What Exactly Changed
The merged work (pull request #44324) adds optional support for compiling systemd programs written in Rust. The support is controlled by a new Meson option, -Drust=, which defaults to auto. If a suitable Rust toolchain is present, the build system can produce Rust-based programs. If it is not, the build continues as before with pure C.
Several important constraints were agreed upon by the maintainers:
- Rust may only be used for new leaf components. These are standalone programs that nothing else in the systemd tree depends on.
- Existing C code will not be ported to Rust for now.
- Core libraries such as libsystemd and libsystemd-shared remain written in C.
- There is no Cargo. All building is done through Meson.
- Only a very restricted set of crates is allowed (primarily core, alloc, and libc). The code is effectively no_std in spirit.
- Rust programs link dynamically against the existing C libsystemd-shared library, just like their C counterparts.
- Bindings are generated at build time using bindgen from the same headers the C library is built with.
In short, the project has created a controlled on-ramp for Rust rather than opening the floodgates.
The First Real Component: systemd-keyring-setup
The concrete motivation for the infrastructure work is a new utility called systemd-keyring-setup. Its job is to provision kernel keyrings early in the boot process and enroll X.509 certificates into the keyrings used by:
- dm-verity
- fs-verity
- BPF
These keyrings are part of the kernel’s integrity and security mechanisms. Having a dedicated, early-boot tool that can load the right certificates and then seal the keyrings is a natural fit for a memory-safe language. Certificate handling and key management are areas where subtle bugs can have serious consequences, so using Rust here is a pragmatic choice rather than a purely ideological one.
At the time the Rust support infrastructure was merged, the systemd-keyring-setup program itself was still in a follow-up pull request. The expectation is that it will land soon now that the foundational support exists.
Why the Maintainers Chose This Approach
systemd has always been cautious about large-scale language changes. The project is written primarily in C, runs on a very wide range of systems, and is a hard dependency for most modern Linux distributions. Any move that increases binary size, complicates the build, or risks destabilizing the boot process faces high scrutiny.
The current design reflects that caution. By restricting Rust to new leaf programs and forbidding Cargo and external crates, the maintainers avoided several common sources of complexity:
- No new package manager in the build system
- No explosion of dependencies
- No risk of pulling large amounts of Rust standard library code into every binary
- No immediate pressure to rewrite mature, well-tested C code
Christian Brauner has noted that the project would eventually like broader Rust support in core components, but current limitations in Rust’s handling of dynamic libraries make that difficult without significantly increasing the size of every binary that links against systemd libraries. Until those issues improve, the leaf-component approach is a practical compromise.
Practical Impact for Distributions and Users
For most end users, nothing will change overnight. Distributions that do not enable the Rust option will continue building and shipping systemd exactly as before. Even distributions that do enable it will only gain the new systemd-keyring-setup tool and any future leaf components written in Rust.
There is a measurable size cost. Early testing showed a simple Rust test program coming out at around 32 KB compared with roughly 20 KB for an equivalent C program (with LTO). On a full desktop system this difference is negligible. On extremely minimal initramfs images or embedded systems, packagers may care more and can simply leave the Rust support disabled.
The toolchain requirements are relatively modern but not extreme: Rust 1.85 or newer, bindgen 0.71.1 or newer, and Meson 1.4 or newer. These versions align with what Debian 13 already ships, which should ease adoption for many distributions.
Broader Context: Rust in the Linux Ecosystem
This change does not exist in isolation. The Linux kernel has been accepting Rust code for drivers and other components for several years. Android has reported significant reductions in memory-safety vulnerabilities after adopting Rust for new code. Other projects in the free software world have been experimenting with similar incremental approaches.
What makes the systemd decision notable is the project’s central position. systemd is not a peripheral tool; it is the init system and service manager for the majority of Linux installations. Allowing even limited Rust components inside it signals that memory safety is no longer viewed as an experimental concern limited to new projects or optional tools.
At the same time, the carefully scoped nature of the change shows that the maintainers are not interested in rewriting the world for its own sake. The goal appears to be pragmatic risk reduction in new code paths rather than a language purity campaign.
What Comes Next
The immediate next step is the landing of systemd-keyring-setup itself and its inclusion in a future release (expected to be systemd 263). After that, the interesting question is whether additional new leaf tools will be written in Rust and how the community and distributions respond.
Longer term, the success of this limited approach could influence whether and when the project attempts to expand Rust usage into more central components. That will depend heavily on improvements in Rust’s dynamic library story and on real-world experience with the current leaf programs.
For now, the message from the systemd project is clear and measured: Rust is welcome for new, self-contained programs. The large body of existing C code remains in place. The boot process and core libraries are not being disrupted. And a concrete security-sensitive tool is being used as the first real test case.
That combination of ambition and restraint is probably the most realistic path forward for introducing modern language features into foundational Linux infrastructure. It will not satisfy those who want a full rewrite tomorrow, and it will not please those who want no Rust at all. But it does give the project a practical way to start reducing memory-safety risk in new code without betting the entire system on an unproven transition.
In the slow-moving world of core system software, that counts as meaningful progress.