Le noyau Linux 6.1, arrivé la semaine dernière, apporte comme d’habitude une longue liste d’améliorations. Il intègre également, et pour la première fois, un code pour la prise en charge du langage Rust. Les conséquences pour les prochaines versions seront importantes, surtout en matière de sécurité.

Le langage Rust a été créé par Mozilla et est arrivé en version 1.0 en mai 2015. Depuis, il est sorti de son giron et est géré par une fondation dédiée. L’attractivité de Rust a explosé ces dernières années, au point que Microsoft a publié une série de billets de blog pour dire tout le bien qu’elle en pensait. La société allait jusqu’à envisager sérieusement Rust comme successeur à C et C++ pour le développement bas niveau, y compris dans Windows, tout en notant des défauts inhérents à la jeunesse du langage.

• Le langage Rust aura sa fondation avant la fin de l'année
• Microsoft se penche sur le langage Rust pour sa programmation système
• Rust a désormais sa fondation, Microsoft au conseil d’administration

Pourquoi un tel succès ? Pour l’apport de sécurité qu’entraine l’utilisation de Rust. Il dispose en effet de caractéristiques le rendant particulièrement adapté au développement bas niveau : un langage « memory safe » à typage fort, avec de très bonnes performances. C’est cette gestion de la mémoire qui intéressait fortement Microsoft. L’entreprise rappelait en effet que 70 % des failles corrigées provenaient de bugs de corruption de mémoire. Des bugs qui ne se seraient pas produits avec un code en Rust.

Il n’était donc pas étonnant que Linus Torvalds, en mars 2021, aborde lui aussi la question, annonçant qu’il n’était pas contre l’idée d’introduire le support de Rust dans le noyau Linux.

L’idée a fait son chemin, puisque la version 6.1 du noyau, récemment sortie, intègre ce support. Il s’agit d’une base minimale, mais sa simple présence indique de grands changements.

Le support de Rust dans le noyau Linux 6.1

12 000 lignes de code ont fait leur apparition dans le noyau et apportent le support initial du cadriciel (framework) Rust. Cela entraine-t-il une modification visible ? Non, il s’agit de la base qui va permettre à d’autres développeurs d’en tirer parti pour proposer des ajouts écrits en Rust.

Concrètement, il est possible désormais de proposer de nouveaux pilotes, sous-systèmes ou modules du noyau en Rust. Ce support s’étend aux règles et scripts de compilation, aux crates et bindings pour la construction minimale, ainsi qu’à la documentation et aux échantillons.

C’est donc une étape cruciale pour l’avenir du noyau, puisque l’enthousiasme généré par le langage a fait de nombreux émules. Le noyau va ainsi commencer à se transformer au cours des prochains mois, puisque non seulement de nouveaux composants – ou des versions remplaçant les anciennes – arriveront, mais le support de Rust va grandir.

On sait déjà que le noyau 6.2 étendra cette prise en charge, incluant un plus grand nombre d’abstractions pour les sous-systèmes.

Mais attention, car s’il est évident que le niveau global de sécurité va augmenter via l’utilisation de Rust, cela ne signifie pas pour autant un blindage imperméable. Le langage permet de se débarrasser de nombreux cas d’erreurs pouvant créer des portes ouvertes, il n’assure pas de lui-même une sécurité à toute épreuve. Dans ce domaine, il reste quand même une amélioration significative par rapport au C utilisé jusque-là dans le noyau.

Les autres évolutions du noyau 6.1

Comme toujours avec les nouvelles versions du noyau Linux, on trouve de nombreux apports et améliorations un peu partout.

L’un des ajouts les plus notables est sans doute l’arrivée de MGLRU, pour « Multi-gen least recently used ». Cet algorithme, initialement développé par Google et largement utilisé dans Android et Chrome OS, a trait à la gestion de la mémoire. Intégré dans le nouveau noyau à la place de l’ancien LRU, il devrait permettre une hausse sensible des performances, particulièrement dans les situations contraintes. Il n’est cependant pas encore activé par défaut.

Pour le reste, la plus grosse partie des apports concerne bien sûr la prise en charge du matériel, avec l’arrivée de nouveaux pilotes un peu partout.

Côté AMD tout d’abord, on note l’arrivée du Cache to Cache et des rapports mémoire devant mener à un meilleur contrôle et des diagnostics plus efficaces. Le support de LbrExtV2 (Last Branch Record Extension v2) est assuré, avec à la clé une amélioration générale des performances pour les processeurs Zen 4. Le PMF (Platform Management Framework) est là lui aussi et fournit un cadre pour exploiter plus efficacement les machines ayant des processeurs AMD, avec des gains audibles sur la ventilation.

Toujours chez AMD, mais pour les cartes graphiques, signalons le support initial des cartes graphiques à architecture RDNA 3 (Radeon 7900 XT et XTX). La mise à jour du pilote permet également quelques corrections pour les autres GPU.

Du mouvement aussi chez Intel, les développeurs ayant posé les bases du support initial pour les futurs processeurs Meteor Lake, gravés en 7 nm. Cette prise en charge comprend notamment celle du Thunderbolt. On trouve par ailleurs des améliorations pour les IGP DG2/Alchemist, mais leur support reste expérimental.

On reste dans le matériel avec le support de plusieurs nouvelles puces ARM, dont les MediaTek MT8186, Texas Instruments AM62A, NXP i.MX8DXL et plusieurs variantes de la Qualcomm IPQ8064. Côté téléphones, les PINE64 PinePhone Pro, Sony Xperia 1 IV, et Samsung Galaxy E5/E7/Grand Max sont officiellement pris en charge. Les puces LoongArch sont mieux supportées, avec par exemple la compatibilité EFI. Même chose pour les puces M1 et M2 d'Apple.

Finissons pour le matériel avec la prise en charge des Surface Pro 9 et Surface Laptop 5 de Microsoft, ainsi que le début du travail préparatoire pour le support du Wi-Fi 802.11be, alias Wi-Fi 7.

Pour les systèmes de fichiers, c’est à nouveau Btrfs qui remporte les améliorations les plus importantes, surtout les tampons asynchrones pour l’écriture des données, ce qui doit doubler les performances dans les opérations de fichiers. On note quand même quelques bonus mineurs pour ext4, XFS et F2FS.

Pas de précipitation

Rappelons que la récupération d’un nouveau noyau dépend avant tout de la distribution utilisée. Si vous avez un système en rolling release de type Arch Linux, openSUSE Tumbleweed ou Solus, la mise à jour est sans doute déjà disponible à l’installation.

Pour les autres, c’est plus compliqué. Si votre Linux ne se base que sur des versions LTS du noyau, c’est peine perdue et il faudra attendre une prochaine mouture à support long. Dans le cas contraire, il faudra vérifier si la distribution intègre un outil permettant de récupérer d’autres versions du noyau, ou en récupérer un comme Mainline pour Ubuntu.

La solution la plus simple, si vous n’êtes pas pressé(e), est d’attendre simplement la mouture suivante de la distribution. Elle aura l’avantage d’avoir un noyau qui aura été testé pour le système. Attention d’ailleurs à la distribution utilisée, car toutes n’utilisent pas un noyau générique. Certaines modifications importantes dans un système pourraient disparaître en installant une version classique du noyau.