Rust sauvera Linux de l'IA, dit Greg Kroah-Hartman
Cela ne veut pas dire pour autant que le responsable du noyau stable de Linux, Greg Kroah-Hartman, pense que Rust est magique.
Points clés de Linux-Terminal.com
- Rust sauvera Linux des faiblesses de sécurité inhérentes au C.
- Linux, confronté à une avalanche 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 sur le langage Rust au monde, à Utrecht, aux Pays-Bas, le mainteneur du noyau Linux stable Greg Kroah-Hartman a commencé en disant : « Je suis ici pour parler des données non fiables et de Linux, et de la manière dont Rust va nous sauver. » Après « un long mois ou deux 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é, tout repose sur vous. »
Sauver? Linux a besoin d'être sauvé ?
Ce dont il parlait était l'afflux soudain de vulnérabilités sérieuses 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 bogues basés sur l'IA.
En conséquence, Kroah-Hartman, qui a « vu chaque bug 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 catégorie de bugs provenant des pièges traditionnels de gestion des erreurs et des ressources en C.
Kroah-Hartman a illustré ces pièges avec de vrais bogues en C dans le noyau, y compris un bogue Bluetooth vieux de 15 ans qui déréférençait un pointeur sans le vérifier, et un bogue Xen où « nous avons oublié de déverrouiller » dans un chemin d'erreur. « La majorité des bogues dans le noyau sont ces petites choses, mineures, » a-t-il expliqué. « Les conditions d'erreur ne sont pas vérifiées, les verrous sont oubliés, les mémoires non libérées fuient, et les vulnérabilités s'accumulent avec le temps. Ils font planter le noyau. C'est ce avec quoi nous vivons en C. C'est pour cela que nous ne l'aimons pas. »
Kroah-Hartman a soutenu que la « meilleure beauté de Rust » est de détecter ces erreurs au moment de la compilation plutôt qu'en révision. Par exemple, lorsqu'il s'agit de 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. »
Il soutenait que ces propriétés supprimaient directement une énorme fraction des bogues qu’il constate : « Cela va nous épargner ces deux choses. D’abord, 60 % des bogues dans le noyau, juste là, ils disparaissent. Merci. » Le gain est une application plus précoce et plus automatisée : « Si cela se produit au moment de la compilation, et non au moment de la révision, ne faites pas de moi un responsable qui doit lire votre code [et] dire : ‘Ah, alors vous vérifiez correctement cette valeur d’erreur. Ah, avez-vous bien pris les verrous à l’endroit approprié ?’ 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 noyau à nettoyer le code C et les interfaces. Il a reconnu 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 noyau et adopté ces idées. Nous vous remercions, vous avez amélioré Linux juste en existant. »
Il a décrit de nouveaux « gardes » C et des verrous avec portée inspirés de Rust : « Maintenant que nous avons cela, nous avons des verrous et des allocateurs C avec portée, et nous avons ajouté ce nouveau code, ce qui rend plus difficile pour nous de faire des erreurs, mais surtout, cela rend la programmation 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 fait correctement parce que vous utilisez ce modèle. Tout est bon, et moins de bogues.' »
Les liaisons Rust imposent également des changements plus profonds du côté C. En se souvenant d'une première conférence Rust-for-Linux, il a dit 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-le. » Il attribue désormais à 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 cœur du pilote, ainsi que l'interaction avec le code C dans le noyau, vont rendre les pilotes plus simples à écrire et plus difficiles à mal écrire... Ils ont fait un travail formidable, vraiment remarquable. »
Au-delà des fonctionnalités du langage, Kroah-Hartman a relié Rust directement à une initiative plus large concernant les données non fiables et l'idée que « toute entrée est malveillante ». Reprenant une phrase de la sécurité chez Microsoft, il a dit aux participants : « Si vous ne retenez rien d'autre de mon intervention, retenez juste ces quatre mots. Cela vient de la sécurité chez 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 le travail 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 réellement du code, cela va simplement donner un indice au compilateur. Vous devez passer par la validation avant d'y accéder réellement. » Le principal avantage pour les réviseurs, a-t-il dit, est que « tout est concentré » sur les points de transition : « Dans une seule 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 à du 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 bogues, 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 ça va éliminer 80 % de toutes les CVE que nous avons, et c’est un chiffre énorme, énorme. »
La rouille n'est pas magique
Maintenant, cela ne veut pas dire 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 dans le noyau : la logique d'affichage des codes QR utilisée lorsque le noyau plante. « Cette logique a été écrite en Rust. Fameusement, 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... Cela pouvait gribouiller partout en mémoire, parce que Rust peut planter tout aussi gravement que C. » Donc, Rust « n'est pas une panacée ».
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 éléments déjà existants dans le noyau avec [Rust] ? » Greg a répondu : « Non, nous ne voulons pas de réécritures, donc à moins que vous ne soyez le responsable 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 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 responsables de ces deux éléments. »
Avec le temps, il s'attend à ce que le support du nouveau matériel penche fortement en faveur de Rust : « Rust va évoluer dans le noyau avec le temps. Certains sous-systèmes ont dit : 'Hé, seuls les nouveaux pilotes pour les graphiques devraient être écrits en Rust.'... Avec le temps, nous avons maintenant atteint un point critique où vous pouvez écrire de très bons pilotes pour tous les différents 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 est une évolution, ce n'est pas un design intelligent. Nous évoluons avec le temps, et avec le temps, de nouveaux pilotes pour le nouveau matériel apparaissent. 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. »
En attendant, Kroah-Hartman a dit au public : « Aujourd'hui, 36 millions de lignes de Linux sont en C, avec 113 000 lignes en Rust. Surtout, cela concerne les bindings. » Comme les pilotes constituent la majeure partie du noyau, « Alice Ryhl, une des meilleures programmeuses Rust pour Android, et les développeurs de Rust-for-Linux, ont dû écrire 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... à moins qu'il y ait un utilisateur pour celui-ci. C’est donc un peu un problème de l’œuf et de la poule. Nous avons dû plier 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 faire tourner Rust sur Linux. »
Ce qui a finalement convaincu un certain nombre de mainteneurs principaux, y compris lui, d’adopter Rust, c’est la façon dont il « facilite la révision du code ». Avec des bots d’intégration continue (CI) qui font respecter les builds et le système de types de Rust qui applique les invariants clés, les mainteneurs peuvent « se concentrer sur la logique » plutôt que sur la gestion des ressources : « Je peux me concentrer sur cette fonction en particulier. Je n’ai pas à m’inquiéter du reste, parce que je suppose que cela fonctionne correctement, puisque cela a été construit correctement. »
En interne, a-t-il dit, les principaux responsables de la maintenance ont déjà pris leur décision sur le statut de Rust : « Les responsables 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 avec Rust était terminée. Ce n'est pas une expérience. C'est réel. » La raison : « Les personnes derrière ce projet sont réelles. Nous leur faisons confiance. Nous savons ce qu'elles font. Elles ont démontré et investi le travail nécessaire pour faire de Rust un langage viable dans le noyau, et nous allons faire en sorte que cela tienne. Allons de l'avant à plein régime. Et, comme toujours, » a-t-il dit avec ironie, « la domination mondiale continue. »
