« Rust sauvera Linux de l'IA », affirme Greg Kroah-Hartman dans le cadre d'une critique de l'usage de l'intelligence artificielle pour trouver les bogues au sein du code du noyau écrit en langage C

« Rust sauvera Linux de l’IA », affirme Greg Kroah-Hartman dans le cadre d’une critique de l’usage de l’intelligence artificielle pour trouver les bogues au sein du code du noyau écrit en langage C

Greg Kroah-Hartman, responsable de la maintenance du noyau stable de Linux, affirme que Rust peut aider Linux à faire face à un afflux de failles de sécurité détectées par l'IA (notamment Dirty Frag, Copy Fail et Fragnesia) en prévenant les erreurs courantes en C liées à la gestion de la mémoire, au verrouillage, à la gestion des erreurs et aux données non fiables dès la phase de compilation, plutôt que lors de la révision par les mainteneurs. Sa sortie est de nature à donner un coup de neuf au débat sur la comparaison entre les langages Rust et C en matière de programmation système.

Ce n'est « pas une solution miracle » et cela ne signifie pas qu'il faille réécrire l'intégralité du noyau, mais Greg Kroah-Hartman est d’avis que les nouveaux pilotes et sous-systèmes doivent s’appuyer sur Rust au fur et à mesure de l’évolution du noyau.

Kroah-Hartman illustre son positionnement à l'aide de véritables bogues en C présents dans le noyau, notamment un bogue Bluetooth vieux de 15 ans qui déréférençait un pointeur sans le vérifier et un bogue Xen d’oubli de déverrouillage dans une branche d'exception. « La majorité des bogues dans le noyau sont de ces petits détails insignifiants », explique-t-il. « Les conditions d'erreur ne sont pas vérifiées, les verrous ne sont pas oubliés, les mémoires non libérées fuient et les vulnérabilités s'accumulent au fil du temps. Elles provoquent le plantage du noyau. C'est ce à quoi nous sommes confrontés avec le C. C'est pourquoi nous ne l'aimons pas. »

Kroah-Hartman fait valoir que « la plus grande beauté de Rust » réside dans le fait de détecter ces erreurs lors de la compilation plutôt que lors de la révision. Par exemple, en matière de verrouillage, il a mis en avant les abstractions de verrouillage de Rust dans le noyau : « La seule façon d’accéder aux pointeurs internes des structures est d’acquérir ce verrou, puis de le libérer automatiquement. Le compilateur s’en charge, c’est sécurisé, le verrouillage s’effectue, tout va bien. Il est tout simplement impossible d’écrire du code pour accéder à ces valeurs sans acquérir le verrou. Le compilateur ne vous le permettra pas. »

Ces propriétés éliminent directement une grande partie des bogues qu’il constate : « Cela va nous éviter deux choses. Premièrement, 60 % des bogues du noyau disparaissent d’un coup. Kroah-Hartman est d’avis que même si Rust disparaissait demain, il a déjà contraint le noyau à nettoyer le code C et les interfaces.


Brian Kernighan pour sa part critique vivement les performances du langage Rust

« Pensez-vous que Rust ait un quelconque intérêt à remplacer C ? Ou s'agit-il simplement d'un énorme battage médiatique qui finira par s'essouffler ? », a demandé un membre du public. Dans un monde qui évolue depuis des années vers des langages plus sûrs pour la mémoire, la réponse d'un fervent défenseur du langage de programmation C depuis plus d'un demi-siècle promettait d'être tout simplement emblématique. Il s'est montré très très critique.

Brian Kernighan a trouvé son expérience avec Rust « pénible ». Selon lui, les mécanismes imposés par Rust pour garantir la sécurité mémoire sont trop lourds, surtout dans un programme où la gestion de la mémoire n’était pas un problème majeur. Il décrit son unique essai comme « une douleur », et juge l’écosystème du langage — avec ses crates, sa complexité et la lenteur de la compilation — comme « incompréhensiblement vaste et lent ».


« Ohhh, Rust », a déclaré Brian Kernighan, sous les rires du public. « Je n'ai écrit qu'un seul programme en Rust, vous devez donc prendre tout cela avec beaucoup de recul. Et j'ai trouvé cela pénible. Je n'arrivais tout simplement pas à comprendre les mécanismes nécessaires pour assurer la sécurité de la mémoire, dans un programme où la mémoire n'était même pas un problème ! ». Sa plus grande critique semble concerner ses performances de Rust.

« Et le compilateur était lent, le code qui en ressortait était lent... », a-t-il déclaré. « Quand j'ai essayé de comprendre ce qui se passait, le langage avait changé depuis la dernière fois que quelqu'un avait publié une description ! Il m'a donc fallu plusieurs jours pour écrire un programme qui, dans d'autres langages, aurait pris peut-être cinq minutes... »

Le 15 mai 2025, le compte Twitter officiel du projet FFmpeg a publié un message acerbe à l'encontre de Rust qui dit : « [Rust] est tellement bon que l'on peut être payé 20 000 $ pour le rendre aussi rapide que C ». Cette remarque visait l'initiative de Prossimo, qui a proposé une prime de 20 000 $ à quiconque parviendrait à rendre son décodeur AV1, rav1d, aussi rapide que dav1d, une implémentation en C largement reconnue pour sa rapidité.

Cette déclaration a ravivé le débat sur les compromis entre sécurité mémoire, performance et coût dans le développement de systèmes critiques. Il s'agit d'un débat de longue date dans la communauté des développeurs. Certains chérissent les performances brutes, tandis que d'autres préfèrent la sécurité.

Certains intervenants pensent que le choix de Rust est une erreur et que C++ moderne est une meilleure alternative

« Maintenant, "pourquoi pas Rust" ? Tout d'abord, Rust utilise une syntaxe différente (souvent, à mon avis, gratuitement), et non seulement tous les développeurs du noyau devraient se familiariser intimement avec la syntaxe afin d'obtenir le même type de "feeling" que nous avons pour le C, mais convertir du code C en Rust n'est pas quelque chose qui ne peut être fait par les développeurs du noyau qu'au coup par coup, alors qu'avec quelques nettoyages le code C existant peut être compilé en C++.

Cependant, je ne suis pas d'accord avec certaines des conclusions de David. en fait, je crois que David est inutilement pessimiste, du moins en ce qui concerne le C++ moderne.

Notez que personne de sain d'esprit ne s'attend à utiliser toutes les fonctionnalités de C++. Tout comme nous avons le "kernel C" (actuellement un sous-ensemble de C11 avec un avec un ensemble relativement large d'extensions spécifiques au compilateur), nous aurions le "noyau C++", que je suggère d'être un sous-ensemble strictement défini de de C++20, combiné à un ensemble similaire d'extensions de compilateur). Je me rends compte que que la prise en charge du C++20 par les compilateurs est encore très récente pour des raisons évidentes, de sorte qu'au moins une partie de ce qui précède est tournée vers l'avenir », souligne le développeur Linux – Peter anvin.

Jiri Slaby de SUSE Lans s'est prononcé en faveur de cette initiative C++ pour le noyau Linux. David Howells de Red Hat s'est également prononcé en faveur de cette approche.

Et vous ?

Le langage C a-t-il réellement besoin d'un remplaçant dans la filière de la programmation système ?
Partagez-vous les avis selon lesquels le choix de Rust comme langage de développement du noyau est une erreur ? Voyez-vous le C++ moderne comme meilleure solution aux questions d’évolution du noyau ?

Voir aussi :

Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents