L'intégration de Rust dans le noyau Linux trouve un autre soutien de poids en Greg Kroah-Hartman

Le mainteneur en chef des versions stables de Linux en souligne les avantages

Le débat sur la politique du noyau Linux concernant le langage de programmation Rust se poursuit... Alors que certains responsables du noyau s'y opposent, Linus Torvalds a clarifié sa position concernant l'intégration de Rust. Greg Kroah-Hartman, le commandant en second de Linux, est également un fervent partisan du code Rust pour le noyau. Il a rédigé un autre message sur la liste de diffusion du noyau Linux soulignant les avantages de Rust et encourageant les nouveaux codes/pilotes du noyau à être en Rust plutôt qu'en C.

Le noyau Linux, pierre angulaire des systèmes d'exploitation basés sur Unix, a longtemps été dominé par le langage C, réputé pour sa puissance mais aussi pour sa complexité et ses failles potentielles en matière de gestion de la mémoire. Depuis quelques années, un changement majeur se dessine avec l'introduction de Rust, un langage moderne conçu pour offrir sécurité et performance. Récemment, Greg Kroah-Hartman, mainteneur en chef des versions stables de Linux et figure influente de la communauté, a réaffirmé son soutien à cette intégration, marquant ainsi une étape décisive dans l'évolution du projet.

Un tournant stratégique pour le développement du noyau

L'idée d’introduire Rust dans le noyau Linux n’est pas nouvelle. Depuis 2021, plusieurs discussions et contributions ont permis d’explorer cette possibilité. La version 6.1 de Linux a marqué une avancée concrète en intégrant les premières bases du support Rust, permettant aux développeurs d’expérimenter et d’évaluer son apport.

Greg Kroah-Hartman, en tant que gardien du bon fonctionnement du noyau, joue un rôle clé dans cette transition. Son soutien explicite témoigne de la maturité du projet et de l’acceptation croissante de Rust parmi les mainteneurs du noyau. Ce choix est motivé par plusieurs avantages qu’offre Rust par rapport à C, notamment :

• Une sécurité mémoire accrue : Rust empêche les erreurs classiques de corruption mémoire grâce à son système de gestion des emprunts et des références.
• Une réduction des vulnérabilités : De nombreuses failles de sécurité dans le noyau sont liées à la gestion manuelle de la mémoire en C, un problème que Rust atténue considérablement.
• Un code plus robuste et maintenable : Les fonctionnalités de Rust, comme son système de types strict et son modèle de concurrence sécurisée, permettent d’écrire un code plus fiable.
  

L’engagement de Greg Kroah-Hartman : un signal fort

Greg Kroah-Hartman n’est pas seulement un observateur de cette transition : il y participe activement. Son engagement en faveur de Rust témoigne de la reconnaissance de ses bénéfices à long terme pour le noyau Linux. Cela indique aussi que les mainteneurs les plus influents du projet sont prêts à soutenir cette modernisation, à condition qu’elle se fasse de manière progressive et bien réfléchie.

Son rôle en tant que mainteneur des versions stables implique qu’il veille à la fiabilité et à la robustesse des nouvelles fonctionnalités introduites. Son soutien signifie donc que l’utilisation de Rust n’est pas simplement une expérimentation, mais bien une évolution concrète et planifiée du noyau.

Greg KH affirme que la grande majorité des bogues du noyau sont dus à de « stupides petits cas de figure en C qui ont totalement disparu en Rust ». Il est tout à fait d'accord pour passer de la base de code C à un nouveau code progressivement en Rust où ces bogues de sécurité de la mémoire et d'autres défauts du C ne sont pas possibles.

Greg reconnaît que tout le code C du noyau Linux ne disparaîtra pas de sitôt, mais il espère que les nouveaux codes/pilotes seront en Rust afin d'éviter les bogues et les problèmes liés au code C.


Les réflexions de Greg Kroah-Hartman sur le sujet

Voici l'intégralité du post LKML de Greg pour ceux qui sont intéressés par ses dernières réflexions sur le code Rust dans le noyau.

« En tant que personne qui a vu presque CHAQUE correction de bogue et problème de sécurité du noyau depuis plus de 15 ans (avec un peu de chance, tous finissent dans les arbres stables, nous en manquons parfois lorsque les mainteneurs/développeurs oublient de les marquer comme corrections de bogue), et qui voit CHAQUE CVE du noyau émise, je pense que je peux parler de ce sujet.

« La majorité des bogues (quantité, pas qualité/gravité) que nous avons sont dus à de stupides petits cas de figure en C qui ont totalement disparu en Rust. Des choses comme de simples écrasements de mémoire (non pas que Rust puisse les attraper tous, loin de là), des nettoyages de chemins d'erreurs, l'oubli de vérifier les valeurs d'erreurs, et des erreurs d'utilisation après la libération. C'est pourquoi je souhaite que Rust soit intégré au noyau, ces types de problèmes disparaissent, permettant aux développeurs et aux mainteneurs de se concentrer sur les VRAIS bogues qui se produisent (c'est-à-dire les problèmes de logique, les conditions de course, etc.)

« Je suis tout à fait d'accord pour faire évoluer notre base de code C afin de rendre ces types de problèmes impossibles à rencontrer, le travail que Kees et Gustavo et d'autres font ici est merveilleux et totalement nécessaire, nous avons 30 millions de lignes de code C qui ne vont nulle part de sitôt. C'est un effort louable qui ne va pas s'arrêter et qui ne devrait pas s'arrêter quoi qu'il arrive.

« Mais pour le nouveau code / les nouveaux pilotes, les écrire en Rust où ces types de bogues ne peuvent tout simplement pas se produire (ou se produisent beaucoup moins) est une victoire pour nous tous, pourquoi ne le ferions-nous pas ? Le C++ ne va pas nous offrir cela de sitôt, et les questions du comité du langage C++ semblent indiquer que tout le monde ferait mieux d'abandonner ce langage dès que possible s'ils souhaitent avoir une base de code qui puisse être maintenue pendant un certain temps.

« Rust nous donne également la possibilité de définir nos apis dans le noyau de manière à ce qu'il soit presque impossible de se tromper lors de leur utilisation. Nous avons beaucoup trop d'apis difficiles / délicates qui nécessitent beaucoup trop de révision de la part du mainteneur juste pour "s'assurer que vous avez bien compris", ce qui est une combinaison de la façon dont nos apis ont évolué au fil des ans (combien de façons différentes pouvez-vous utiliser une 'struct cdev' de manière sûre ?) et de la façon dont le C ne nous permet pas d'exprimer les apis d'une manière qui les rend plus faciles/plus sûres à utiliser. Forcer les mainteneurs de ces apis à les repenser est une bonne chose, car cela nous oblige à les nettoyer pour TOUT le monde, y compris les utilisateurs de C, ce qui rend Linux meilleur dans l'ensemble.

« Et oui, les bindings Rust me semblent magiques par endroits, moi qui n'ai que très peu d'expérience en Rust, mais je suis prêt à apprendre et à travailler avec les développeurs qui se sont portés volontaires pour nous aider. Il ne faut pas vouloir apprendre et changer sur la base de nouvelles preuves (voir mon point sur la lecture de tous les bogues du noyau que nous avons).

« Rust n'est pas une "solution miracle" qui résoudra tous nos problèmes, mais il est certain qu'il aidera dans un grand nombre d'endroits, donc pour les nouvelles choses à venir, pourquoi ne le voudrions-nous pas ? Linux est un outil que tout le monde utilise pour résoudre ses problèmes, et ici nous avons des développeurs qui disent "hey, notre problème est que nous voulons écrire du code pour notre matériel qui ne peut pas avoir tous ces types de bugs automatiquement".

« Pourquoi l'ignorerions-nous ?

« Oui, je comprends notre problème de mainteneurs surchargés (étant moi-même l'une de ces personnes), mais ici nous avons des gens qui font réellement le travail !

« Oui, les bases de code en langage mixte sont difficiles à maintenir, mais nous sommes des développeurs de noyau, bon sang, nous maintenons et renforçons Linux depuis plus longtemps qu'on 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 été capable d'accomplir. L'ajout d'un autre langage ne devrait pas être un problème, nous avons géré des choses bien pires par le passé et nous ne devrions pas abandonner maintenant notre volonté d'assurer le succès de notre projet pour les 20 prochaines années. Nous devons continuer à aller de l'avant lorsque nous sommes confrontés à de nouvelles bonnes idées, et accueillir les personnes qui proposent de nous rejoindre pour faire le travail afin de s'assurer que nous réussissons tous ensemble ».


[B]Une position qui n'est pas unanime[...