Rust est désormais officiel dans le noyau Linux — et la sécurité mémoire devient une politique de sécurité

L'amélioration de sécurité la plus conséquente de l'histoire de l'informatique n'est peut-être pas un nouveau système d'authentification, un pare-feu plus intelligent ou un meilleur système de détection. Il pourrait s'agir de changer le langage de programmation dans lequel les systèmes d'exploitation sont écrits.

Les vulnérabilités de sécurité mémoire — bugs use-after-free, dépassements de tampon, déréférencements de pointeur nul, dépassements d'entier qui deviennent des dépassements de tampon — représentent environ 70 % des CVE de haute sévérité de Microsoft depuis des années. Google rapporte des chiffres similaires pour Chrome et Android. La NSA a publié des directives indiquant qu'environ 70 % de toutes les vulnérabilités logicielles exploitables sont des problèmes de sécurité mémoire. Ce ne sont pas des cas marginaux obscurs — ce sont la classe la plus courante de vulnérabilités exploitables, et elles sont courantes depuis quarante ans parce que la plupart du code des systèmes d'exploitation est écrit en C et C++, des langages qui rendent facile d'écrire du code non sûr pour la mémoire et difficile de détecter les bugs jusqu'à ce que quelque chose plante en production.

Rust élimine toute la catégorie. Pas en ajoutant un ramasse-miettes au moment de l'exécution — Go et Java adoptent cette approche, et cela coûte des performances que les systèmes d'exploitation ne peuvent pas se permettre. Au lieu de cela, Rust utilise un borrow checker au moment de la compilation qui suit la propriété et les durées de vie de chaque morceau de mémoire au moment de la construction. Si vous écrivez du code qui pourrait produire un bug use-after-free, le compilateur Rust refuse de le compiler. L'erreur mémoire ne se produit pas à l'exécution. Elle échoue à la compilation avec un message d'erreur vous indiquant exactement ce qui ne va pas. Pas de crash, pas de CVE, pas de cycle de correctifs, pas de correctif d'urgence expédié à 3 heures du matin.

Le jalon du noyau Linux

Le noyau Linux est le fondement d'Android, de la plupart des infrastructures cloud et d'un vaste éventail de systèmes embarqués. Il est également écrit presque entièrement en C — environ 27 millions de lignes accumulées sur trente ans. Ajouter un nouveau langage de programmation à une base de code aussi ancienne et aussi critique est une décision qui nécessite des années de validation avant de devenir une politique officielle.

Le premier code Rust a été fusionné dans le noyau Linux avec la version 6.8 en décembre 2023. Les implémentations initiales couvraient le pilote GPU Asahi (prenant en charge les Mac Apple M1 et M2 sous Linux) et une partie de l'infrastructure du pilote NVMe — des domaines où de nouveaux développements avaient lieu et où le risque de casser des fonctionnalités existantes était minimisé. C'était une preuve de concept que Rust pouvait fonctionner dans les contraintes strictes du noyau et coexister avec la base de code C existante.

En décembre 2025, le projet du noyau Linux a officiellement déclaré que Rust dans le noyau n'était plus expérimental. Le développement du noyau Rust fait désormais partie intégrante du processus de développement du noyau, avec les mêmes garanties de stabilité, exigences de test et normes de révision de code que le développement C. De nouveaux sous-systèmes du noyau peuvent être écrits en Rust en toute confiance que Rust restera un langage pris en charge par le noyau à long terme — un engagement qui ne pouvait pas être pris auparavant car la désignation expérimentale signifiait que l'infrastructure Rust du noyau pouvait être supprimée si cela ne fonctionnait pas.

Cela a une importance pratique pour plusieurs raisons. Les développeurs de pilotes peuvent écrire de nouveaux pilotes en Rust sans incertitude quant à l'existence de l'infrastructure Rust du noyau dans la prochaine version du noyau. Les composants du noyau critiques pour la sécurité — piles réseau, pilotes de systèmes de fichiers, sous-systèmes cryptographiques — peuvent être systématiquement réécrits en Rust au fil du temps, réduisant ainsi la surface d'attaque du code qui s'exécute actuellement avec des privilèges ring-0 et traite des entrées externes non fiables. Et cela signale à la communauté plus large de la programmation système que Rust est un choix sérieux à long terme pour le travail sur le noyau, ce qui affecte les décisions d'embauche, de formation et d'investissement dans les outils à travers l'industrie.

L'adoption de Rust par Android et ses résultats

Google a commencé à ajouter Rust à Android en 2021 et a été le plus transparent en mesurant les résultats. En 2024, Google a rapporté qu'environ 77 % du nouveau code Android est écrit en Rust — un chiffre reflétant le nouveau code ajouté à la plateforme, et non la base de code C et C++ existante, qui reste en grande partie telle quelle et continue d'être maintenue.

L'impact mesurable sur la sécurité est significatif. Le taux de vulnérabilités de sécurité mémoire découvertes dans Android a diminué d'année en année depuis 2019, la même période pendant laquelle l'adoption de Rust a commencé. Google attribue cela directement au choix du langage : le code Rust fonctionnant dans Android ne produit pas de CVE de sécurité mémoire au même rythme que le code C, car le compilateur empêche toute la classe de bugs avant que le code ne soit expédié.

La pile Bluetooth d'Android, des parties de la pile réseau et des composants de l'infrastructure des codecs multimédia ont été réécrits en Rust. Ce sont exactement les surfaces d'attaque qui ont historiquement produit des vulnérabilités de haute sévérité — elles traitent des entrées externes non fiables (paquets d'appairage Bluetooth, données réseau, fichiers vidéo provenant de sources non fiables) avec une logique d'analyse complexe où une seule erreur de décalage peut devenir une vulnérabilité d'exécution de code à distance exploitable sans interaction de l'utilisateur.

L'approche de Microsoft

L'adoption par Microsoft de langages sécurisés pour la mémoire est répartie sur plusieurs initiatives plutôt qu'une seule directive centralisée. L'équipe du noyau Windows a évalué Rust pour le développement de nouveaux pilotes de noyau, et Microsoft contribue activement au projet Rust pour Windows qui fournit des liaisons Rust aux API Windows. L'infrastructure Azure a adopté Rust dans plusieurs composants. Le projet Hyperlight de Microsoft — un hyperviseur léger conçu pour exécuter des fonctions serverless à grande échelle — a été construit en Rust dès le départ.

Plus largement, Microsoft s'est engagé à écrire un nouveau code critique pour la sécurité dans des langages sécurisés pour la mémoire (ce qui inclut Rust, Go et C# aux côtés des langages sûrs plus anciens Swift et Java) et à réécrire systématiquement le code C et C++ existant dans des alternatives sécurisées pour la mémoire lorsque le risque de sécurité justifie le coût d'ingénierie. Ce n'est pas une directive "tout réécrire en Rust" — c'est une approche priorisée par le risque qui concentre les réécritures sécurisées pour la mémoire sur le code qui traite des entrées externes et s'exécute avec des privilèges élevés, ce qui est exactement là où les bugs mémoire se traduisent en vulnérabilités exploitables.

Les véritables défis

Les garanties de sécurité mémoire de Rust viennent avec de véritables compromis qui comptent pour l'adoption dans le monde réel :

La courbe d'apprentissage est raide. Le borrow checker applique des règles de propriété qui semblent peu familières aux développeurs venant de C, C++ ou de la plupart des autres langages. "Se battre avec le borrow checker" est une frustration courante pour les développeurs nouveaux à Rust. Google estime qu'il faut six mois à un an pour qu'un développeur C expérimenté devienne véritablement productif en Rust sur une grande base de code. À grande échelle, c'est un investissement significatif en formation et en recrutement.

L'interopérabilité avec C est nécessaire mais complexe. Toute stratégie de migration réaliste implique Rust appelant C et C appelant Rust — traversant la frontière FFI entre les deux langages. Cette frontière nécessite des blocs Rust unsafe, qui peuvent introduire les mêmes bugs mémoire que Rust empêche. Bien faire les frontières FFI nécessite une ingénierie soigneuse, et chaque bloc unsafe a besoin d'une révision minutieuse.

Les temps de compilation sont plus longs. L'analyse du borrow checker est coûteuse en calcul. Les grandes bases de code Rust compilent significativement plus lentement que les bases de code C équivalentes, ce qui affecte la vitesse d'itération des développeurs et les temps de pipeline CI/CD. C'est un problème connu sur lequel l'équipe Rust travaille activement, mais cela reste un coût réel.

La base de code existante ne va nulle part rapidement. Le noyau Linux a 27 millions de lignes de C. Déplacer cela progressivement vers Rust prendra de nombreuses années, et le code C existant continuera de produire des vulnérabilités de sécurité mémoire tout au long de cette transition. Le passage aux langages sécurisés pour la mémoire est structurel et générationnel — il prévient les nouvelles vulnérabilités dans le nouveau code, pas les bugs existants dans le code existant.

La dimension politique

Le développement le plus significatif récent n'est pas une étape technique — c'est le passage de la recommandation technique à la politique de sécurité. La CISA, la NSA et leurs équivalents Five Eyes ont tous publié des directives formelles indiquant que les développeurs de logiciels ont la responsabilité d'utiliser des langages sécurisés pour la mémoire pour le nouveau code critique pour la sécurité. La stratégie nationale de cybersécurité de la Maison Blanche mentionne explicitement la sécurité mémoire. Ce cadrage change l'équation pour les organisations qui écrivent des logiciels traitant des données sensibles ou des infrastructures critiques.

Ce n'est plus purement une décision technique. C'est une question de savoir si une organisation peut défendre ses choix de langage auprès des régulateurs, des auditeurs et des clients. La combinaison de la maturité technique — les outils, l'écosystème et la documentation de Rust se sont considérablement améliorés depuis 2021 — et la pression politique formelle accélèrent l'adoption au-delà de ce que le seul cas technique entraînerait.

La sécurité mémoire est un problème résolu dans la théorie des langages de programmation. En faire la valeur par défaut pratique dans l'infrastructure des systèmes d'exploitation est un projet d'ingénierie générationnel. Le jalon du noyau Linux, les métriques d'adoption d'Android et le changement de politique indiquent tous que ce projet est passé d'un exercice académique à une réalité d'ingénierie — lentement, avec des aspérités, et sur une échelle de temps mesurée en décennies plutôt qu'en cycles de produits. La direction est claire, et l'élan est réel.