Alors, faut-il aujourd’hui réécrire tout le noyau Linux avec le langage Rust ? Cette discussion ne date pas d’aujourd’hui et s’est accentuée depuis l’apparition de la première version stable de Rust en 2015. Au regard des possibilités offertes par Rust, certains proposent de le faire. Cette année, lors de la conférence Linux Plumbers en août, les intervenants ont, une fois encore, eu le temps d’en discuter. Ils semblent être d'accord à l’unanimité, non pas pour réécrire le code existant en Rust, mais pour que le développement du noyau se poursuive en utilisant Rust. C’est-à-dire qu’ils envisagent un monde où les nouveaux morceaux de codes pourraient être écrits en Rust.Le langage de programmation Rust a longtemps eu pour objectif de remplacer le C dans le développement du noyau Linux. Au fur et à mesure que Rust a mûri, plusieurs développeurs ont exprimé un intérêt croissant pour son utilisation dans le noyau Linux. Lors de la conférence virtuelle Linux Plumbers de 2020, le volet de la microconférence LLVM a organisé une session sur les questions ouvertes et les obstacles à l'acceptation de Rust en amont dans le noyau Linux. L'intérêt pour ce sujet est visible, car cette session a été la plus suivie de l'événement 2020.
Cette session s'est appuyée sur les travaux antérieurs de nombreux développeurs, notamment une conférence donnée l'année passée par Alex Gaynor et Geoffrey Thomas lors du sommet sur la sécurité de Linux. Lors de la conférence, ils ont présenté leur travail de prototypage des modules du noyau Rust et ont plaidé pour l'adoption de Rust dans le noyau. Ils ont cité des travaux qui montrent qu'environ deux tiers des vulnérabilités du noyau auxquelles ont été attribués des CVE dans Android et Ubuntu sont toutes liées à des problèmes de sécurité de la mémoire.
Ils ont fini en expliquant que Rust peut complètement éviter cette classe d'erreur grâce à des API plus sûres activées par son type de système et son vérificateur d'emprunt. Cette étude a réussi à convaincre plusieurs mainteneurs, et Linus Torvalds, qui ont donné leur aval à l'introduction de Rust dans le noyau. Thomas et Gaynor, Josh Triplett, coresponsable de l'équipe du langage Rust et développeur de longue date du noyau Linux, ainsi qu'un certain nombre d'autres développeurs intéressés, ont participé à la discussion sur le sujet.
Ils ont brièvement évoqué leur travail jusqu'à présent et certaines de leurs premières réflexions et questions avant d'ouvrir la majeure partie du temps à la discussion. Ils ont donné un bref exemple de ce à quoi pourrait ressembler le code Rust en mode noyau. Les participants ont souligné qu'ils ne proposent pas de réécrire le noyau Linux entier en Rust ; ils se concentrent uniquement sur l'évolution vers un monde où un nouveau code pourrait être écrit en Rust. La discussion qui a suivi s'est concentrée sur trois domaines de préoccupation potentielle pour le support de Rust.
Il s’agit de l’utilisation des API existantes dans le noyau, le support de l'architecture et une question sur la compatibilité ABI entre Rust et C. En effet, ils estiment dans un premier temps que l’introduction de Rust dans l’arborescence doit obligatoirement respecter les API C existantes. Selon eux, pour être utile au développement du noyau, il ne suffit pas que Rust soit capable de générer du code pouvant être lié au noyau ; il faut aussi que Rust puisse accéder au grand nombre d'API utilisées dans le noyau Linux, qui sont toutes actuellement définies dans des fichiers d'en-tête C.
Rust dispose d'un bon support pour l'interopérabilité avec le code C, y compris pour l'appel de fonctions utilisant l'ABI C et pour la définition de fonctions avec des ABI compatibles C qui peuvent être appelées depuis le C. De plus, l'outil bindgen est capable d'analyser les fichiers d'en-tête C pour produire les déclarations Rust appropriées, de sorte que Rust n'a pas besoin de dupliquer les définitions du C, ce qui permet aussi de vérifier le type de langage. En apparence, ces caractéristiques font que Rust est bien équipé pour s'intégrer aux API C existantes.
Cependant, tous estiment que le diable est dans les détails, et tant le travail effectué jusqu'à présent que la conversation lors de la session ont révélé quelques défis ouverts. Par exemple, Linux fait un usage intensif des macros de préprocesseur et des fonctions en ligne, qui ne sont pas aussi facilement prises en charge par l’outil bindgen et l'interface de fonctions étrangères de Rust. Les intervenants ont également relevé d’autres détails qui méritent une attention particulière. Dans un second temps, Rust doit prendre en charge l’architecture existante.
Selon eux, actuellement, l’unique implémentation Rust mature est le compilateur rustc, qui émet du code via LLVM. Le noyau Linux prend en charge un large éventail d'architectures, dont plusieurs n'ont pas de backend LLVM disponible. Pour quelques autres, un backend LLVM existe, mais rustc ne le supporte pas encore. Les présentateurs ont voulu comprendre si la prise en charge complète de l'architecture était un obstacle à l'activation de Rust dans le noyau Linux. Et dans ce cas, comment Rust peut-il alors résoudre le problème ?
Beaucoup ont proposé d'implémenter dans Rust des pilotes qui ne seraient jamais utilisés sur les architectures les plus obscures. De son côté, Triplett a suggéré que l'ajout de Rust dans le noyau aiderait à augmenter la prise en charge de l'architecture pour Rust, en citant son expérience avec le projet Debian. Il a mentionné que l'introduction du logiciel Rust dans Debian a aidé à motiver les enthousiastes et les utilisateurs d'architectures de niche à améliorer le support de Rust, et il s'attend à ce que l'ajout du support au noyau ait un effet similaire.
En particulier, il était convaincu que toute architecture avec un backend LLVM serait rapidement supportée par Rust. La discussion a aussi porté sur les implémentations alternatives de Rust comme une voie vers un support plus large de l'architecture. Par exemple, le projet mrustc est un compilateur Rust expérimental qui émet du code C. Son utilisation peut potentiellement permettre à Rust d'être compilé via le même compilateur C que celui qui compile le reste du noyau. En outre, Triplett a fait part de son intérêt et de son travail pour un frontal Rust pour GCC.
Cela peut permettre à Rust de cibler toutes les architectures prises en charge par GCC. Ce projet n'en est qu'à ses débuts, mais il représente une voie pour combler le fossé de l'architecture à l'avenir. La conclusion de cette section est un peu incertaine, mais il ne semble pas y avoir de forte opposition à l'idée de soutenir les pilotes de périphériques Rust sans attendre une prise en charge plus large de l'architecture. Enfin, le dernier volet auquel Rust doit répondre pour être utilisé dans le code Linux est la compatibilité de l'ABI avec le noyau.
En fait, puisque Rust est (actuellement) compilé via LLVM, et que le noyau est le plus souvent construit avec GCC, lier le code de Rust dans le noyau peut signifier mélanger le code émis par GCC et LLVM. Même si LLVM vise à être compatible ABI avec GCC, il y a eu un certain retour de bâton en raison des craintes que cette façon de faire ne crée un risque d'incompatibilité ABI subtile. Les participants à la discussion se sont demandé si la communauté des noyaux ne préférait pas limiter le support de Rust aux noyaux construits avec Clang afin d'assurer la compatibilité.
Selon Greg Kroah-Hartman, un autre participant à la discussion, la règle actuelle du noyau est que la compatibilité n'est garantie que si tous les fichiers objet du noyau sont construits avec le même compilateur, en utilisant des drapeaux identiques. Cependant, il s'est également déclaré favorable à la liaison des objets Rust construits par LLVM dans un noyau construit par GCC, à condition que les objets soient construits en même temps, avec les options appropriées définies, et que les configurations résultantes soient entièrement testées.
Florian Weimer, un autre participant à vidéoconférence, a précisé que les questions relatives à l'ABI ont tendance à se situer dans des coins obscurs du langage, par exemple renvoyer une structure contenant un champ binaire par valeur. Cela dit, Triplett a souligné que les appels entre GCC et Rust étaient routiniers et très répandus dans l'espace utilisateur, et que du côté de Rust, il n'a donc aucun problème de compatibilité. Il semble que cette préoccupation ne devrait pas, en fin de compte, être un obstacle à l'introduction de Rust dans le noyau.
La session s'est terminée sans autre étape spécifique, mais il semble que, dans l'ensemble, il y ait un enthousiasme pour soutenir les modules Rust et un accord croissant sur les exigences générales de ce soutien. La prochaine grande étape sera probablement lorsque quelqu'un proposera un véritable pilote Rust à inclure dans le noyau. Un cas d'utilisation concret et une mise en œuvre contribuent toujours à forcer la clarté sur les questions litigieuses restantes et les décisions de conception.
Source : LWN.net
Et vous ?
Quel est votre avis sur le sujet ? Êtes-vous d'avis pour le développement du noyau de Linux en Rust ? Pourquoi ? Selon vous, devrait-on reprendre tout le noyau en Rust ? Pourquoi ?Voir aussi
L'année 2020 est-elle celle de Rust au sein du noyau Linux ? C'est ce que suggère une sortie de Linus Torvalds qui donne des instructions sur l'introduction de son support au système de build « Il est vraiment difficile de trouver des mainteneurs » : Linus Torvalds parle de la prochaine génération de responsables du développement de Linux à l'occasion de la conférence Open Source Summit Rust : les développeurs révèlent pourquoi ils ne sont pas plus nombreux à utiliser le langage de programmation, en pointant du doigt un manque d'adoption en entreprise, d'après un sondage Le langage Rust est la meilleure chance offerte à l'industrie informatique pour la mise sur pied d'applications système sécurisées, d'après Microsoft « Rust est le futur de la programmation système et C le nouvel assembleur », d'après un ingénieur d'Intel qui explique pourquoi il est pertinent de passer à Rust 
Envoyé par N_BaH
