systemd Embraces Rust but Draws the Line at Core Libraries

systemd developers explain why Rust is welcome in standalone components but cannot yet be used in core shared libraries.

Following systemd’s recent decision to officially support Rust, developers Christian Brauner and Lennart Poettering published a detailed explanation of how the language will be integrated into the project and where it won’t be used.

The main limitation concerns systemd’s core shared libraries. While Rust can be used to develop standalone executables, the project’s central libraries, including libsystemd-shared.so, will remain written in C.

According to the developers, the main obstacle is Rust’s lack of first-class shared library support and a stable ABI. Without these, integrating Rust into systemd’s shared libraries would result in duplicated Rust code across multiple libraries and executables.

That would be particularly problematic for systemd, which currently has more than 180 binaries. Static linking may work well for standalone programs, but the developers consider it inconvenient for the project’s core infrastructure.

Instead, systemd will expose its existing C functionality through Rust crates, allowing Rust-based executables to access the same internal APIs as their C counterparts. This ensures programs written in either language behave consistently, including command-line handling, help messages, and error reporting.

The developers clarified why systemd rejected Cargo, Rust’s standard build and dependency management tool. The project will continue using Meson exclusively, avoiding the complexity of maintaining two build systems. Security and software supply-chain concerns associated with Cargo were also cited.

External Rust crates are another area where systemd will proceed cautiously. Although third-party dependencies are not ruled out, the maintainers want more experience with the Rust ecosystem before accepting them.

For now, Rust components will operate without Rust’s standard library, using the no_std approach. Instead, they rely on systemd’s existing functionality, including its security-sensitive filesystem operations.

Another important clarification concerns existing C code. The maintainers explicitly reject rewriting established components in Rust simply to change programming languages. They argue replacing C with Rust does not automatically address security problems, particularly when the primary attack surface involves filesystem path handling rather than memory safety.

So, Rust support will remain optional. The developers acknowledge Rust does not support every architecture currently supported by systemd, so builds without Rust will remain fully functional and supported.

Bobby Borisov

Bobby Borisov

Bobby, an editor-in-chief at Linuxiac, is a Linux professional with over 20 years of experience. With a strong focus on Linux and open-source software, he has worked as a Senior Linux System Administrator, Software Developer, and DevOps Engineer for small and large multinational companies.

Leave a Reply

Your email address will not be published. Required fields are marked *