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....
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
