systemd accueille ses premiers programmes en Rust, sans Cargo et sans réécrire le C
Le 24 octobre 2026, systemd fusionne dans son dépôt Git le support des programmes écrits en Rust, une brique qui débouchera sur l’utilitaire systemd-keyring-setup. L’objectif n’est pas de porter le C existant mais de laisser les composants feuilles profiter de la sûreté mémoire de Rust, pour un surcoût binaire de quelques kilo-octets.
24 octobre 2026. systemd fusionne dans son dépôt Git l’infrastructure qui permet d’écrire des programmes systemd en Rust, en alternative au C. 24 octobre 2026, même jour. Le premier composant concerné, systemd-keyring-setup, attend encore sa fusion, désormais débloquée par cette brique. 24 octobre 2026, encore. Les mainteneurs précisent qu’ils ne porteront pas le code C existant. Le point clé : le cœur de systemd reste en C, mais les composants périphériques peuvent désormais naître en Rust — sans Cargo, compilés par Meson et limités à une liaison C.
Pour un administrateur Linux qui voit systemd gérer le démarrage de la quasi-totalité des distributions, c’est une bascule discrète mais symbolique : le socle d’init le plus répandu du monde open source entame sa transition vers un langage pensé pour éliminer une classe entière de bugs mémoire.
Ce qui a été fusionné, précisément
Le changement de fond est étroit. Il rend possible l’écriture de programmes systemd — les composants feuilles comme les utilitaires et les services individuels — en Rust, mais pas encore celle du code cœur : la bibliothèque systemd et les briques centrales restent en C, faute de résoudre au préalable certains bloqueurs propres à Rust.
Les contraintes posées par les mainteneurs sont nettes. Le Rust de systemd se construit avec Meson, sans Cargo, et impose une liaison C uniquement : le nouveau code s’intègre au reste de l’écosystème par la frontière C habituelle, sans faire entrer l’écosystème de compilation Cargo dans la chaîne de build.
Le premier composant écrit dans ce nouveau cadre est systemd-keyring-setup, un utilitaire chargé d’approvisionner les keyrings et d’inscrire des certificats X.509 dans les keyrings du noyau dm-verity, fs-verity et BPF pendant le démarrage, avant de les traiter par la suite. Son code n’est pas encore fusionné, mais les mainteneurs le présentent comme imminent : à l’origine, tout faisait partie d’un seul gros commit, découpé ensuite entre l’activation du Rust, systemd-keyring-setup et les préparations annexes.
Le support est optionnel, piloté par l’option Meson -Drust=, dont la valeur par défaut est auto. Une cible de systemd 263, la version en cours de préparation, l’activera de manière transparente quand un compilateur Rust est présent.
Pourquoi Rust dans systemd, et pourquoi maintenant
La motivation n’est pas esthétique. Le noyau Linux accepte du Rust depuis la version 6.1, et la pression en faveur de la sûreté mémoire s’est installée durablement dans l’infrastructure des systèmes : une part significative des failles exploitées dans les logiciels bas niveau reste due à des erreurs de gestion mémoire en C. systemd est un point de passage critique — il démarre les services, monte les systèmes de fichiers et gère les sockets — et chaque bug à cet endroit se paie au prix fort.
Le contexte interne de systemd va dans le même sens. La version 262, sortie peu avant, a introduit un « canary » IA/LLM destiné à détecter les contributions de code non relues, ainsi que l’intégration LUO : le projet cherche à encadrer la qualité d’un code de plus en plus produit par des assistants. Permettre à Rust de prendre pied dans les composants feuilles est une autre réponse au même problème — réduire à la source la surface des bugs, plutôt que la détecter après coup.
Les mainteneurs sont explicites sur ce qu’ils ne feront pas : pas de portage du C existant vers Rust. Le nouveau langage servira au code neuf, là où une réécriture n’a pas de coût de régression, pas à une migration rétrospective des millions de lignes déjà en production.
Ce mouvement s’appuie sur des chiffres solides. Microsoft comme Google attribuent depuis des années environ 70 % de leurs failles de sécurité à des erreurs de sûreté mémoire dans des langages comme C et C++, et les deux éditeurs poussent publiquement vers des langages qui éliminent ces classes de bugs à la racine. Le noyau Linux a ouvert la voie en acceptant Rust dès la version 6.1, et systemd — premier processus utilisateur de la quasi-totalité des distributions — en est l’étape suivante logique : c’est lui qui démarre les services, monte les systèmes de fichiers et, désormais, approvisionne les keyrings de vérification d’intégrité.
Le coût : quelques kilo-octets, et des limites assumées
La transition n’est pas gratuite, mais elle est mesurée. Les composants Rust sortent légèrement plus gros que leurs jumeaux C : dans les essais, un programme de test pesait 32 Ko contre 20 Ko pour son équivalent C. Pour des binaires système embarqués dans un initramfs, cet écart compte ; il reste marginal à l’échelle d’un système complet.
Les limites sont assumées et documentées. Le cœur de systemd — la bibliothèque centrale et le code partagé — n’accueille pas encore Rust, et les mainteneurs listent des bloqueurs à lever avant d’envisager cette étape. La liaison C obligatoire signifie aussi que le code Rust de systemd ne profitera pas, pour l’instant, des idiomes plus riches qu’autoriserait une intégration native.
Ce qui est déjà en place suffit à ouvrir la voie : la fusion de l’infrastructure Rust permet à n’importe quel composant feuille futur d’être écrit dans un langage à sûreté mémoire, sans changer l’outillage de build du projet.
Le choix de systemd-keyring-setup comme premier composant n’est pas anodin : il manipule des certificats X.509 et des keyrings du noyau dès les premières secondes du démarrage, à un endroit où une fuite mémoire ou une corruption de buffer se paie par un système qui ne démarre pas ou par des secrets exposés. Y déployer Rust en priorité, c’est durcir l’endroit où l’échec coûte le plus cher.
Ce que cela change pour les administrateurs
Dans l’immédiat, rien ne casse. Le support Rust est désactivé par défaut tant que l’option -Drust= n’est pas explicitement activée, et aucune version stable ne l’impose encore. Les distributions qui construiront systemd 263 avec un compilateur Rust présent l’activeront automatiquement via la valeur auto, mais sans changement visible à l’exécution : un binaire Rust se comporte comme un binaire C une fois lancé.
Ce qui change, c’est la trajectoire. Chaque nouveau composant écrit en Rust — à commencer par systemd-keyring-setup — réduit la surface de bugs mémoire dans un exécutable qui s’exécute tôt, souvent avant que les mécanismes de journalisation et de confinement ne soient pleinement opérationnels. Pour un administrateur, c’est une raison de suivre de près les notes de version de systemd 263, en particulier la liste des composants migrés et l’état de l’option -Drust= dans le paquet de sa distribution.
Pour les mainteneurs de distribution, la question pratique est celle du paquetage : parce que le support Rust est optionnel et piloté par un drapeau Meson plutôt que par Cargo, il n’impose pas d’introduire le registre Cargo dans les chaînes de build — une concession réelle pour celles et ceux qui construisent les paquets. C’est précisément pourquoi l’option vaut auto par défaut : elle ne s’active que si une chaîne Rust est déjà présente, et reste invisible sinon.
Verdict
La bascule est prudente et la direction est la bonne. Si vous maintenez une distribution ou construisez systemd vous-même, laissez l’option -Drust= sur auto : le surcoût binaire est minime et la valeur se concrétisera composant par composant. Si vous êtes simple exploitant, vous n’avez rien à faire aujourd’hui — mais notez que systemd 263 marquera le début d’une période où le socle d’init du système accueillera progressivement du code Rust. La leçon vaut plus largement : la sûreté mémoire gagne l’infrastructure par les feuilles, pas par une réécriture du cœur — et c’est précisément parce que cette méthode est lente qu’elle a une chance de réussir.