Linux et Rust : quand l’innovation technique rencontre la résistance humaine

Depuis plusieurs mois, le noyau Linux, ce pilier de l’écosystème open source écrit en C depuis 1991, traverse une période de turbulences inédite. L’intégration du langage Rust, initiée en 2022, devait apporter plus de sécurité au système d’exploitation. Pourtant, elle provoque aujourd’hui des conflits ouverts entre mainteneurs, au point que certains développeurs clés ont démissionné de leurs fonctions. En février 2025, la situation a atteint un point de tension critique qui soulève une question fondamentale : comment faire cohabiter innovation technique et stabilité d’un projet vieux de plus de trente ans ?

Pourquoi Rust entre dans Linux : une question de sécurité

L’arrivée de Rust dans le noyau Linux ne relève pas d’un simple effet de mode. Ce langage de programmation, créé en 2006, offre une caractéristique fondamentale : la sécurité de la mémoire garantie à la compilation. Contrairement au C, où les erreurs de gestion mémoire comme les dépassements de tampon (buffer overflow), les pointeurs invalides ou les accès après libération sont courantes, Rust les détecte avant même l’exécution du programme.

Greg Kroah-Hartman, mainteneur de la branche stable du noyau Linux et figure respectée du projet, a récemment pris position publiquement sur le sujet. Dans un message adressé à la liste de diffusion du noyau Linux en février 2025, il affirme avoir observé « presque tous les correctifs de bugs et problèmes de sécurité du noyau pendant plus de 15 ans ». Son constat est sans appel : la majorité des bugs proviennent de « petits cas particuliers stupides en C qui sont totalement absents dans Rust ».

Ces vulnérabilités représentent environ deux tiers des failles de sécurité du noyau. Pour Kroah-Hartman, utiliser Rust pour les nouveaux pilotes et modules permettrait aux mainteneurs de se concentrer sur les problèmes réellement complexes, comme les conditions de concurrence et les erreurs logiques, plutôt que sur des bugs évitables.

Le projet Rust for Linux, lancé en 2020, a franchi une première étape importante en octobre 2022 lorsque Linus Torvalds a accepté l’intégration du langage dans le noyau 6.1. Les premiers pilotes écrits en Rust sont apparus dans la version 6.8 en décembre 2023. Avec la version 6.13, sortie en janvier 2025, Kroah-Hartman a même évoqué un « point de bascule », annonçant l’arrivée de nombreux pilotes Rust dans les prochaines versions.

Le conflit de février 2025 : quand les tensions explosent

Le 5 février 2025, une proposition technique apparemment anodine a mis le feu aux poudres. Un correctif permettant aux pilotes de périphériques écrits en Rust d’accéder à l’API DMA du noyau a été soumis pour intégration. Cette fonctionnalité est nécessaire pour que les pilotes Rust puissent gérer efficacement les entrées et sorties de données.

Christoph Hellwig, mainteneur du sous-système DMA du noyau, a opposé un refus catégorique en quelques mots : « pas de code Rust dans kernel/dma, s’il vous plaît ». Sa position est rapidement devenue plus explicite. Interrogé par Danilo Krummrich, ingénieur logiciel chez Red Hat impliqué dans le projet Rust for Linux, sur les alternatives possibles, Hellwig a clarifié son refus : « Ne me forcez pas à travailler avec votre langage brillant du jour. Maintenir des projets multi-langages est une douleur que je n’ai aucun intérêt à gérer. »

Plus tard, dans un message devenu célèbre, Hellwig a comparé les bases de code multi-langages à un « cancer » qui se propage aux sous-systèmes essentiels. Il a précisé que sa critique visait spécifiquement la cohabitation de plusieurs langages, et non Rust en tant que tel. Selon lui, l’absence de frontières internes a permis au noyau Linux de survivre et de prospérer pendant des décennies, et l’ajout d’un autre langage menace cet équilibre.

Cette controverse a conduit Hector Martin, responsable du projet Asahi Linux qui vise à porter Linux sur les puces Apple Silicon, à demander publiquement à Linus Torvalds de trancher. Martin a même défendu l’utilisation des réseaux sociaux pour faire pression, affirmant que cela permettait de contrer l’hostilité de certains mainteneurs envers Rust.

La réponse de Torvalds a été cinglante. Le créateur de Linux a reproché à Martin son approche : « Et si vous acceptiez le fait que le problème, c’est peut-être vous ? ». Torvalds a défendu le processus de développement actuel et critiqué ce qu’il considère comme du « brigading » sur les réseaux sociaux. Suite à cet échange, Martin a démissionné de sa position de mainteneur Linux le 7 février 2025, déclarant ne plus avoir « aucune confiance dans le processus de développement du noyau ou l’approche de gestion de la communauté ».

La position nuancée de Linus Torvalds sur Linux et Rust

Contrairement à certaines interprétations, Linus Torvalds n’est pas opposé à Rust dans le noyau. Au contraire, lors de l’Open Source Summit Europe en août 2024, il a reconnu que les désaccords avaient pris des « connotations de guerre presque religieuse », mais a maintenu son soutien au projet.

En février 2025, Torvalds a clarifié sa position dans un message détaillé à Christoph Hellwig. Le principe est simple mais ferme : les mainteneurs qui refusent de gérer le code Rust ne sont pas obligés de s’en occuper. Cependant, en contrepartie, ils n’ont pas non plus leur mot à dire sur ce code. Selon Torvalds, refuser de traiter avec Rust ne signifie pas avoir un droit de veto sur toute intégration Rust.

Il a souligné que le correctif controversé ne touchait même pas directement la couche DMA maintenue par Hellwig. Les liaisons Rust fonctionnent comme une interface séparée entre l’API C inchangée et les pilotes Rust. Torvalds a été clair : « Vous n’êtes pas forcé d’accepter du code Rust, ni de vous soucier du code Rust dans le code DMA. Vous pouvez l’ignorer. Mais ‘ignorer le côté Rust’ signifie automatiquement que vous n’avez aucun pouvoir sur le côté Rust. »

Selon plusieurs sources, Torvalds aurait même confié en privé qu’il serait prêt à intégrer du code Rust contre l’avis de certains mainteneurs. Cette information, bien que non officiellement confirmée, témoigne de sa détermination à faire avancer le projet.

Les arguments des opposants à Rust dans Linux

Les critiques de l’intégration de Rust ne se résument pas à de simples réticences au changement. Plusieurs préoccupations techniques et organisationnelles légitimes sont soulevées.

La première concerne la complexité de maintenance d’un projet multi-langage. Hellwig insiste sur le fait que chaque morceau supplémentaire de code qu’un autre langage ajoute multiplie les risques et les difficultés. Pour lui, Linux a prospéré précisément parce qu’il n’avait pas de frontières internes fortes entre les sous-systèmes. L’ajout de Rust crée ces frontières et complique la collaboration.

Certains développeurs estiment également que Rust n’est pas adapté à certaines structures de données fondamentales du noyau. Des critiques ont noté qu’il est particulièrement difficile, voire impossible, d’implémenter certains types de listes chaînées en Rust de la manière dont elles sont utilisées dans Linux. Le système de propriété de Rust, bien que sécurisant, impose des contraintes qui peuvent entrer en conflit avec les pratiques établies depuis des décennies.

Au-delà des aspects techniques, une dimension humaine importante émerge : la question de la charge de travail. Les mainteneurs du noyau, déjà surchargés, craignent que l’intégration de Rust n’augmente leur fardeau. Même si les abstractions Rust sont maintenues par une équipe dédiée, toute modification de l’API C peut potentiellement casser le code Rust, créant des dépendances supplémentaires à gérer.

Enfin, certains voient dans le mouvement pro-Rust une forme d’arrogance. Des développeurs C expérimentés ont l’impression que les partisans de Rust remettent en question leur expertise et leurs décisions architecturales prises au fil des années. Cette dimension psychologique ne doit pas être sous-estimée dans un projet où les relations humaines sont aussi importantes que le code.

Les bénéfices concrets de Rust dans le noyau Linux

Malgré les tensions, l’intégration de Rust progresse et commence à montrer des résultats tangibles. La version 6.13 du noyau, sortie en janvier 2025, a apporté des améliorations significatives au support de Rust, notamment des modules en place, des liaisons étendues et des événements de traçage pour les développeurs Rust.

Greg Kroah-Hartman, fort de son expérience de plus de 15 ans à observer les bugs du noyau, liste les types d’erreurs que Rust élimine naturellement : les écrasements de mémoire simples (bien que Rust ne les attrape pas tous), les erreurs de nettoyage dans les chemins d’erreur, l’oubli de vérifier les valeurs d’erreur, et les erreurs d’utilisation après libération.

Ces bugs représentent la majorité quantitative des problèmes rencontrés, même s’ils ne sont pas nécessairement les plus graves. En les éliminant, les mainteneurs peuvent consacrer plus de temps aux véritables problèmes complexes, comme les erreurs logiques et les conditions de concurrence, que même Rust ne peut pas totalement prévenir.

Les performances ne sont pas sacrifiées. Les benchmarks montrent que les pilotes Rust fonctionnent au même niveau que leurs équivalents en C, grâce aux abstractions à coût zéro de Rust. Le langage compile vers des instructions machine optimisées sans surcharge d’un ramasse-miettes, répondant aux exigences d’efficacité du noyau.

Plusieurs grandes entreprises technologiques soutiennent financièrement et techniquement l’intégration de Rust dans Linux. Google, Microsoft, Amazon et Meta ont tous des ingénieurs dédiés à temps plein au projet Rust for Linux. Ce soutien institutionnel garantit des ressources à long terme pour le projet.

Selon Josh Aas, qui supervise le projet Prossimo de l’Internet Security Research Group axé sur la sécurité mémoire, la présence de code Rust augmente dans divers sous-systèmes de Linux : les pilotes PHY, le pilote de bloc null, le générateur de code QR pour le panic screen DRM, le pilote binder d’Android, entre autres.

La voie vers une cohabitation apaisée

Miguel Ojeda, responsable du projet Rust for Linux, a publié en février 2025 une « politique du noyau Rust » pour clarifier les règles de cohabitation. Ce document vise à rassurer les contributeurs Rust et à définir les attentes des deux côtés.

Le principe central est que les sous-systèmes peuvent décider individuellement de leur approche vis-à-vis de Rust. Certains peuvent choisir d’ignorer complètement le code Rust, d’autres peuvent l’embrasser activement, et beaucoup se situeront probablement entre ces deux extrêmes. Un mainteneur peut être conscient des liaisons Rust et disposé à collaborer sans être profondément impliqué dans le code Rust lui-même.

Ojeda a également précisé qu’un sous-système peut temporairement accepter que du code Rust soit cassé lors de modifications de l’API C. L’intention est de faciliter l’adoption amicale de Rust sans imposer un fardeau aux mainteneurs existants qui travaillent sur des correctifs urgents côté C. Toutefois, ces cassures doivent être réparées aussi rapidement que possible, idéalement avant d’atteindre Linus Torvalds.

Cette approche pragmatique reconnaît que les 30 millions de lignes de code C du noyau ne disparaîtront pas de sitôt. L’objectif n’est pas de réécrire Linux en Rust, mais d’utiliser Rust là où il apporte une valeur ajoutée évidente, principalement pour les nouveaux pilotes et modules.

Kroah-Hartman l’exprime clairement : « Oui, les bases de code multi-langages sont difficiles et pénibles à maintenir, mais nous sommes des développeurs du noyau, bon sang. Nous maintenons et renforçons Linux depuis plus longtemps que quiconque ne l’aurait cru possible. Nous avons transformé notre modèle de développement en une merveille d’ingénierie bien huilée, créant quelque chose que personne d’autre n’a jamais pu accomplir. Ajouter un autre langage ne devrait vraiment pas être un problème. »

Quelles perspectives pour Linux et Rust ?

Le débat autour de Rust dans Linux reflète une tension inhérente à tout projet mature : comment innover tout en préservant la stabilité ? Comment attirer une nouvelle génération de développeurs tout en respectant l’expertise accumulée ?

L’avenir semble néanmoins pencher vers une intégration progressive de Rust. Avec le soutien explicite de Linus Torvalds et de Greg Kroah-Hartman, les deux figures les plus influentes du projet, Rust a gagné une légitimité qui dépasse les oppositions individuelles. La démission de Christoph Hellwig de son poste de mainteneur DMA en février 2025, remplacé par Marek Szyprowski, illustre que le projet avance malgré les résistances.

Les prochaines versions du noyau devraient voir une augmentation du nombre de pilotes Rust. La version 6.14, dont la fenêtre de fusion s’est ouverte en janvier 2025, apporte déjà des améliorations significatives, notamment l’utilisation de fonctionnalités Rust stables, rapprochant le projet d’une compilation sans fonctionnalités expérimentales.

Cependant, le chemin reste semé d’embûches. L’écosystème Rust pour le noyau doit encore mûrir. Les outils de débogage, l’intégration continue et la documentation doivent s’améliorer. La communauté doit également apprendre à mieux communiquer, en évitant les confrontations qui ont marqué les premiers mois de 2025.

D’ici 2045, dans vingt ans, à quoi ressemblera le noyau Linux ? Aura-t-il encore des allocations de ressources non vérifiées automatiquement ? Des accès mémoire hors limites possibles ? Si la réponse est non, alors quelque chose doit changer dans les vingt prochaines années. Rester uniquement en C ne permettrait pas d’atteindre cet objectif.

La question n’est donc plus de savoir si Rust fera partie de l’avenir de Linux, mais comment gérer cette transition de manière à préserver à la fois l’innovation technique et l’harmonie communautaire. Le défi est autant humain que technique, et c’est peut-être là la leçon la plus importante de ce conflit de février 2025.

---

Questions fréquentes