Rust sauvera Linux de l'IA, dit Greg Kroah-Hartman
Cela ne signifie pas pour autant que le responsable du noyau stable Linux, Greg Kroah-Hartman, pense que Rust est magique.
Principaux points à retenir de Linux-Terminal.com
- Rust sauvera Linux des faiblesses de sécurité inhérentes au C.
- Linux, confronté à un flot de problèmes de sécurité découverts par l'IA, pourrait utiliser de l'aide.
- À l'avenir, de plus en plus de code Linux sera écrit en Rust.
Lors de la conférence Rust Week, la plus grande conférence au monde sur le langage Rust, à Utrecht, aux Pays-Bas, le mainteneur du noyau stable de Linux, Greg Kroah-Hartman, a commencé en disant : « Je suis ici pour parler des données non fiables et de Linux, et de la façon dont Rust va nous sauver. » Après « un mois ou deux passés sur la liste de sécurité du noyau », il a poussé ce point encore plus loin : « Je vais même faire une déclaration plus audacieuse et dire : 'Vous allez sauver Linux.' Désolé, c'est entièrement sur vous.
Sauver ? Linux a besoin d'être sauvé ?
Ce dont il parlait, c'était l'afflux soudain de graves failles de sécurité Linux découvertes, telles que Dirty Frag, Copy Fail et Fragnesia, qui ont été mises en lumière grâce aux derniers programmes de détection de bugs basés sur l'IA.
En conséquence, Kroah-Hartman, qui a « vu tous les bugs de sécurité du noyau depuis 2005 », a déclaré que l'équipe du noyau publie maintenant « 13 CVE [Vulnérabilités et Expositions Communes] par jour, ou quelque chose comme ça, quelque chose de fou ». Il pense que Rust est l'une des rares façons réalistes de réduire la classe de bugs qui proviennent des pièges traditionnels de gestion des erreurs et des ressources en C.
Kroah-Hartman a illustré ces écueils avec de vrais bugs C dans le noyau, notamment un bug Bluetooth vieux de 15 ans qui déréférençait un pointeur sans le vérifier, et un bug Xen où « on a oublié de déverrouiller » dans un chemin d’erreur. « La majorité des insectes dans le noyau sont de petites choses mineures », expliqua-t-il. « Les conditions d'erreur ne sont pas vérifiées, les verrous ne sont pas oubliés, les souvenirs non publiés fuient, et les vulnérabilités s'accumulent avec le temps. Ils font planter le noyau. C’est ce que nous vivons dans C. C'est pour ça qu'on n'aime pas ça. »
Kroah-Hartman a soutenu que la « meilleure beauté de Rust » réside dans la détection de ces erreurs au moment de la compilation plutôt que lors de la révision. Par exemple, en ce qui concerne le verrouillage, il a souligné les abstractions de verrouillage de Rust dans le noyau : « La seule façon d'accéder aux pointeurs internes des structures est de prendre ce verrou et de libérer le verrou automatiquement. Le compilateur le fait, c'est protégé, le verrou se produit, tout est heureux. Vous ne pouvez tout simplement pas écrire du code pour accéder à ces valeurs... sans prendre le verrou. Le compilateur ne vous le permettra pas. »
Ces propriétés, soutenait-il, éliminent directement une grande fraction des bugs qu’il observe : « Cela va nous épargner ces deux choses. D'abord, 60 % des bugs dans le noyau juste là, ils disparaissent. Merci. » Le bénéfice se situe dans une application plus précoce et plus automatisée : « Si cela se produit au moment de la compilation, pas lors de la révision, ne faites pas de moi un mainteneur qui doit lire votre code [et] dire : 'Ah, alors vous vérifiez correctement cette valeur d'erreur. Ah, avez-vous correctement pris les verrous au bon endroit ?' Rust nous donne cela gratuitement. C’est la meilleure chose qui soit.
Même si Rust disparaissait demain, a soutenu Kroah-Hartman, il a déjà obligé le kernel à nettoyer le code et les interfaces en C. Il a crédité directement l'influence de Rust : « Nous avons volé cela à Rust. Merci. C'est une bonne idée, donc si Rust disparaissait demain, nous avons tellement nettoyé le code C dans le kernel et adopté les idées. Nous vous remercions, vous avez amélioré Linux simplement en existant. »
Il a décrit de nouvelles « gardes » en C et des verrous à portée, inspirés de Rust : « Maintenant que nous avons cela, nous avons des verrous et des allocateurs à portée en C, et nous avons ajouté ce nouveau code, ce qui rend plus difficile pour nous de nous tromper, mais surtout, cela rend le codage plus simple. » Avec plus de 5 000 développeurs et seulement environ 700 mainteneurs, il a déclaré que le temps de révision est la ressource la plus rare -- donc les modèles qui rendent la correction évidente sont cruciaux : « Nous optimisons pour que le code soit facile à réviser... Si je peux réviser votre code plus facilement, je peux y jeter un coup d'œil et dire : 'Hé, regardez, vous avez évidemment raison parce que vous utilisez ce modèle. Tout est bon, et moins de bugs.' »
Les liaisons Rust imposent également des changements plus profonds du côté C. Se remémorant une conférence Rust-for-Linux, il a déclaré que lorsqu'il a vu « des centaines de lignes de code Rust pour gérer deux lignes de code C », il a réalisé : « Je peux changer le code C. Nous pouvons changer le code C pour rendre le code Rust plus simple. Nous n'avons aucun problème à changer les deux côtés de cette barrière. Faisons cela. » Il attribue maintenant à l'équipe Rust-for-Linux le mérite d'avoir remodelé les interfaces des pilotes : « Les règles impliquées, et la façon dont les traits et les interfaces fonctionnent pour le noyau des pilotes, et l'interaction avec le code C dans le noyau vont rendre les pilotes plus faciles à écrire et plus difficiles à mal écrire... Ils ont fait un travail formidable, formidable. »
Au-delà des fonctionnalités du langage, Kroah-Hartman a lié Rust directement à une initiative plus large concernant les données non fiables et l'idée que « toute entrée est malveillante ». Empruntant une phrase à la sécurité de Microsoft, il a dit aux participants : « Si vous ne vous souvenez de rien d'autre de mon discours, souvenez-vous simplement de ces quatre mots. Cela vient de la sécurité de Microsoft il y a de nombreuses années. Ils ont compris que toute entrée est malveillante. Vous devez valider toutes les entrées. »
Il a décrit les travaux en cours sur un wrapper de type « non fiable » et une méthode de validation en Rust qui oblige à une validation explicite au moment où les données passent de non fiables à fiables. « Nous avons quelque chose appelé non fiable pour l'ajouter aux données, et chaque fois que vous voulez réellement accéder à ces données, ce n’est qu’un type, ce n’est pas vraiment du code, cela va indiquer au compilateur. Vous devez passer par la validation avant d’y accéder réellement. » Le principal avantage pour les examinateurs, a-t-il dit, est que « tout est concentré » sur les points de transition : « Dans une section du code, vous pouvez voir tout le code qui effectue la validation de la transformation des données de l’espace utilisateur, des données non fiables vers des données fiables, en un seul endroit. »
Ce modèle s'étend à un matériel de plus en plus hostile : « Le modèle et les noyaux, nous ne faisons même pas confiance au matériel. Le matériel est plein de bugs, mais maintenant vous pouvez avoir du matériel malveillant, et nous voyons de plus en plus de matériel malveillant. » Son objectif est de marquer ces données comme non fiables et de les suivre à travers le système de types, puis de concentrer l'énergie de révision : « C'est ce qui va vraiment nous sauver, parce que nous ne faisons pas confiance aux données... je pense que je vais faire cette citation non scientifique. C'est ce qui va sauver Linux, la combinaison de tout le reste et des données non fiables. Je pense que cela va éliminer 80 % de tous les CVE que nous avons, et c'est un chiffre énorme, énorme. »
Rust n'est pas magique
Cela ne signifie pas qu'il pense que Rust est magique. Ce n'est pas le cas. Il a cité l'un des premiers composants Rust intégrés au noyau : la logique d'affichage de code QR utilisée lorsque le noyau plante. « Cette logique a été écrite en Rust. Familièrement, elle avait un bug de mémoire. On lui a donné un tampon et sa taille, et le reste du code n'a jamais vérifié la taille du tampon... Elle pouvait écrire partout en mémoire, car Rust peut planter tout aussi mal que C. » Donc, Rust « n'est pas une solution miracle. »
Il n'encourage pas non plus quelqu'un à réécrire le noyau Linux en Rust. Un participant a demandé : « Encouragez-vous réellement à réécrire des choses qui existent déjà dans le noyau avec [Rust] ? » Greg a répondu : « Non, nous ne voulons pas de réécritures, donc à moins que vous ne soyez le mainteneur et propriétaire de ce fichier, faites-le seulement pour les nouvelles choses. Laissez le code C existant tranquille, et évoluons à partir de là. » Il a donné Binder, la communication interprocessus (IPC) centrale d'Android, comme exemple où les implémentations en C et en Rust coexistent temporairement pour atteindre la parité, après quoi « ils vont supprimer le code C, parce que j'ai confiance en eux, et ils sont les propriétaires et mainteneurs de ces deux éléments. »
Au fil du temps, il s'attend à ce que le support du nouveau matériel penche fortement vers Rust : « Rust va évoluer dans le noyau au fil du temps. Certains sous-systèmes ont dit : 'Hé, seuls les nouveaux pilotes pour la vidéo devraient être écrits en Rust.'... Au fil du temps, nous avons maintenant atteint un point critique où vous pouvez écrire de très bons pilotes pour tous les types de sous-systèmes en Rust et Linux. Je pense que dans un an ou deux, vous verrez cela. » Dans le style typique de Kroah-Hartman, il a résumé le modèle comme étant évolutif : « Linux, c'est l'évolution, ce n'est pas un design intelligent. Nous évoluons au fil du temps, et au fil du temps, de nouveaux pilotes pour le nouveau matériel sont ajoutés. Vous commencerez à utiliser ce nouveau matériel. L'ancien pilote ne sera tout simplement plus utilisé. Finalement, nous les supprimerons, comme nous le faisons après environ 20 ans. »
Entre-temps, Kroah-Hartman a déclaré au public : « Aujourd'hui, 36 millions de lignes de Linux sont en C, avec 113 000 lignes en Rust. Par-dessus tout, cela consiste en des bindings. » Comme les pilotes constituent la majeure partie du noyau, « Alice Ryhl, une programmeuse Rust Android de premier plan, et les développeurs de Rust-for-Linux ont dû créer des bindings pour tout afin de pouvoir écrire un petit pilote en Rust. » Cela a obligé la communauté à assouplir sa règle habituelle contre le code inutilisé : « Nous n'aimons pas non plus ajouter du code au noyau qui n'est pas utilisé, donc il est difficile d'ajouter un binding... sauf si vous avez un utilisateur pour celui-ci. C'est donc un peu un problème de l'œuf et de la poule. Nous avons dû assouplir un peu cette règle. »
Il a également signalé des déploiements dans le monde réel à venir : « Les téléphones Android vont sortir, espérons-le bientôt, exécutant tout le code [Rust] dans Binder. Donc encore une fois, des milliards d'appareils pourront bientôt exécuter Rust sous Linux. »
Ce qui a finalement convaincu un certain nombre de mainteneurs principaux, y compris lui, à propos de Rust, c'est la façon dont il « facilite la relecture du code ». Avec les bots CI (Intégration Continue) qui font respecter les builds et le système de types de Rust qui applique des invariants clés, les mainteneurs peuvent « se concentrer sur la logique » plutôt que sur la gestion des ressources : « Je peux me préoccuper de cette fonction. Je n'ai pas à m'inquiéter du reste, car je suppose que cela fonctionne correctement, puisque cela a été construit correctement. »
En interne, a-t-il dit, les principaux mainteneurs ont déjà pris leur décision sur le statut de Rust : « Les mainteneurs du noyau Linux, nous nous réunissons chaque année et discutons de ce que font les processus. L'année dernière, nous avons dit que l'expérience Rust était terminée. Ce n'est pas une expérience. C'est pour de vrai. » La raison : « Les personnes derrière cela sont réelles. Nous leur faisons confiance. Nous savons ce qu'elles font. Elles ont montré et fourni le travail nécessaire pour faire de Rust un langage viable dans le noyau, et nous allons faire en sorte que cela tienne. Allons-y à pleine vitesse. Et, comme toujours », a-t-il dit avec un sourire ironique, « la domination mondiale continue. »