La réécriture en Rust : Pourquoi Windows et Linux abandonnent enfin le C/C++

Depuis quarante ans, le monde numérique tient ensemble grâce à l’équivalent informatique du duct tape et de quelques prières : le C et le C++. Du système d’exploitation de votre portable au firmware de votre micro-ondes, ces langages ont donné aux développeurs un contrôle absolu sur le matériel. Mais ce pouvoir est venu avec une faille fatale.

Avant de lire : Nous avons déjà parlé de la façon dont Valve a contourné le monopole de Windows au niveau de l’OS dans Le coup d’État silencieux de Proton. Mais sous ces deux systèmes d’exploitation, une guerre architecturale beaucoup plus profonde se joue actuellement au niveau du noyau lui-même.

Table des matières

• Le problème des 70 pour cent
• Linus Torvalds et les portes de l’enfer
• La capitulation silencieuse de Microsoft
• Le retour à la réalité
• Faits amusants
• Sources

Le problème des 70 pour cent

Honnêtement, je ne pensais jamais voir le jour où le gouvernement américain se mêlerait de nos choix de compilateurs. Mais plus tôt cette année, le Bureau du directeur cybernétique national de la Maison Blanche (ONCD) a publié un rapport sans équivoque exhortant l’industrie de la tech à abandonner le C et le C++ au profit de langages à mémoire sécurisée.

Ils ne l’ont pas fait par passion soudaine pour la syntaxe moderne. Ils l’ont fait à cause des mathématiques.

Microsoft et Google ont tous deux publié des données indépendantes montrant qu’environ 70 % de toutes leurs vulnérabilités de sécurité critiques dans Windows et Chrome sont des problèmes de sécurité de la mémoire. On parle ici de dépassements de tampon, de bugs use-after-free et de lectures hors limites. Déboguer une vulnérabilité use-after-free en C++, c’est comme essayer de trouver une fuite de gaz avec un briquet. Vous la trouvez généralement, mais vous ne survivez pas à la découverte.

Pendant des années, la solution de l’industrie était simplement de « coder mieux ». Nous avons construit des outils d’analyse statique et des sanitizers à n’en plus finir. Rien n’a fonctionné. Les êtres humains ne peuvent tout simplement pas écrire des millions de lignes de gestion manuelle de la mémoire sans se planter. C’est là qu’entre en jeu Rust.

Linus Torvalds et les portes de l’enfer

Si vous connaissez un peu le créateur de Linux, Linus Torvalds, vous savez qu’il déteste viscéralement le C++ et qu’il a farouchement gardé le noyau Linux comme un sanctuaire exclusivement réservé au C depuis 1991. Proposer un nouveau langage pour le noyau était généralement considéré comme un suicide professionnel.

Pourtant, fin 2022, Torvalds a officiellement fusionné le support initial de Rust dans Linux 6.1.

Remplacer le C dans le noyau Linux, c’est comme essayer de changer les fondations de l’Empire State Building pendant que les gens travaillent encore au 80e étage. Mais la communauté Linux a réalisé que le borrow checker de Rust — une fonctionnalité de compilation notoirement stricte qui refuse de compiler votre code s’il détecte des bugs de mémoire potentiels — était le seul moyen d’arrêter l’hémorragie interminable des correctifs de sécurité. Rust garantit la sécurité de la mémoire à la compilation sans avoir besoin d’un ramasse-miettes (garbage collector), ce qui signifie qu’il s’exécute exactement aussi vite que le C.

La capitulation silencieuse de Microsoft

Du côté de Redmond, Microsoft subit un changement encore plus radical. Le noyau Windows est une bête monolithique, traînant des décennies de code hérité. L’un de ses composants les plus tristement célèbres est Win32k.sys, le sous-système de gestion graphique et de fenêtrage qui a été une mine d’or pour les attaquants cherchant des exploits d’élévation de privilèges.

Microsoft réécrit activement des parties centrales du noyau Windows, y compris Win32k, en Rust. L’entreprise qui a littéralement bâti son empire sur Visual C++ livre maintenant du code Rust au cœur de son système d’exploitation phare. Quand Microsoft admet que le C++ est trop dangereux pour l’espace noyau, le débat est officiellement clos.

Le retour à la réalité

Franchement, la foule du « Rewrite it in Rust » peut être insupportable. Ils traitent le langage comme un artefact religieux qui guérit toutes les maladies logicielles. La réalité sur le terrain est beaucoup plus rude.

Les temps de compilation de Rust sont abyssaux. Si vous êtes habitué à l’itération rapide du développement web moderne, compiler une base de code massive en Rust vous donnera amplement le temps de remettre en question vos choix de vie. La courbe d’apprentissage est également un mur de briques ; les développeurs doivent désapprendre des décennies d’habitudes orientées objet et se battre contre le compilateur pendant des semaines avant d’avoir le déclic.

Nous ne verrons pas le C et le C++ disparaître demain. Il y a des milliards de lignes de code hérité qui font tourner le système financier mondial, l’infrastructure aérospatiale et les vieux moteurs de jeu. Mais le choix par défaut pour la nouvelle programmation système a irrémédiablement changé. L’ère de la gestion manuelle de la mémoire touche à sa fin, et honnêtement, bon débarras.

Faits amusants

• L’épiphanie de l’escalier : Le créateur de Rust, Graydon Hoare, a été inspiré pour commencer à travailler sur le langage en 2006 après que l’ascenseur de son immeuble soit tombé en panne à cause d’un bug logiciel, le forçant à monter 21 étages à pied.
• C’est quoi un Segfault au juste ? Le terme segmentation fault remonte aux années 1960 avec le système d’exploitation Multics, qui utilisait des segments de mémoire physique. Lorsqu’un programme essayait d’accéder à un segment qui ne lui appartenait pas, le système générait une « faute ».

Sources

• Rapport du White House Office of the National Cyber Director (ONCD) sur la sécurité de la mémoire (2024)
• Microsoft Security Response Center : “A proactive approach to more secure code”
• Projet Google Chromium : “Memory safety in Chrome”
• Linux Kernel Mailing List (LKML) : Support de Rust fusionné dans la version 6.1