systemd limits Rust to standalone components, keeps core libraries in C

systemd maintainers Christian Brauner and Lennart Poettering have published a detailed policy explaining how Rust will be integrated into the project following its recent official adoption of the language. Rust is permitted for standalone executables, but core shared libraries including libsystemd-shared.so will remain in C. The decision stems from Rust's missing stable ABI and inadequate shared library support, which would cause code duplication across systemd's more than 180 binaries if static linking were used for core infrastructure.

The project will expose existing C functionality through Rust crates to ensure consistent behavior across languages, and will use Meson exclusively while rejecting Cargo for build and dependency management. Rust components will initially use no_std rather than Rust's standard library, relying on systemd's existing security-sensitive filesystem operations. Rust support remains optional and builds without it will stay fully functional, as Rust does not support all architectures systemd targets.

Rust integration boundaries in systemd

• Shared library limitation: Rust lacks first-class shared library support and a stable ABI, making it unsuitable for systemd's core shared libraries like libsystemd-shared.so; static linking would duplicate Rust code across 180+ binaries.
• C API exposure: systemd will provide Rust crates wrapping existing C functionality, ensuring Rust-based executables access the same internal APIs as C components with consistent command-line handling, help messages, and error reporting.
• Build system rejection: Cargo is excluded in favor of Meson exclusively, avoiding dual build system maintenance and addressing security and supply-chain concerns with Rust's standard package manager.
• no_std approach: Initial Rust components will operate without Rust's standard library, depending instead on systemd's established security-sensitive filesystem operations and internal utilities.
• No mandatory rewrites: Existing C components will not be rewritten in Rust solely for language change; maintainers argue memory safety does not automatically resolve security issues when attack surfaces involve filesystem path handling.

Why it matters

This policy provides a pragmatic template for other large C-based Linux infrastructure projects considering Rust adoption, demonstrating how to incrementally introduce memory-safe languages without destabilizing core library ABIs that distributions depend on. For Linux distribution maintainers, the optional Rust support and Meson-only build system reduces packaging complexity and avoids Cargo ecosystem dependencies, while the no_std approach limits supply-chain exposure. The explicit rejection of wholesale C-to-Rust rewrites pushes back against language-rewriting as a security panacea, focusing attention instead on actual attack surfaces.