Le noyau Linux 6.1 pose les premières briques de la compatibilité avec Rust

Le noyau Linux 6.1 pose les premières briques de la compatibilité avec Rust

C rouillé

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

15/12/2022
33

Le noyau Linux 6.1 pose les premières briques de la compatibilité avec Rust

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.

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.

33

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Le support de Rust dans le noyau Linux 6.1

Les autres évolutions du noyau 6.1

Pas de précipitation

Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

Commentaires (33)


pamputt Abonné
Le 15/12/2022 à 15h 01

Ah mon avis, l’arrivé de Rust dans le noyau est un très grand pas en avant. Ca va prendre du temps mais de plus en plus de drivers devraient être codés dans ce langage plus sûr et avec de très bonne performance.


Wosgien Abonné
Le 15/12/2022 à 16h 48

A priori, ça va aller de plus en plus vite.



Rust est un vrai langage, bien pensé, qui prend en compte les problématiques et opportunités actuelles.



Il peut être un peu abrupt dans la syntaxe, mais dans l’esprit, c’est juste. (il n’y a pas d’erreur, j’ai écrit “juste” en tant qu’adjectif comme dans le verbe “ajuster”).



Chapeau bas Mozilla pour ce langage.



L’acceptation dans le noyau Linux est une véritable (peut-être la véritable) reconnaissance de la valeur de cet outil.


aurel32 Abonné
Le 15/12/2022 à 20h 41

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.



Ben non justement, la version 6.1 est une version LTS.


WeKeys Abonné
Le 15/12/2022 à 21h 43

Oui Kernel 6.1 est LTS, mais l’auteur parlait du système d’exploitation LTS, exemple Ubuntu 22.04 LTS.
Impossible sans tweaker le système d’installer le kernel 6.1 dessus, il ne sera pas proposé par Canonical.


Ghimo Abonné
Le 16/12/2022 à 07h 50

Bien que le language continue de mûrir, peut-on envisager que le kernel puisse passer à 100% en Rust à moyen / long terme ?


Le 16/12/2022 à 09h 11

Dans 15 ou 20 ans peux être. Ça me semble compliquer quand même.


Furanku Abonné
Le 16/12/2022 à 09h 15

Je ne pense pas. Je ne sais même pas s’il y aurait intérêt à cela, chaque langage ayant ses atouts et inconvénients. Mais le cadre est posé, va être amélioré, et permettra aux développeurs de choisir selon les besoins (Rust ne met pas fin à C).


Gautier. Abonné
Le 16/12/2022 à 10h 21

De ce que j’ai pu lire, c’est pas du tout l’esprit pour l’instant. Pour l’instant, Rust n’est prévu que pour des drivers, pas pour des composants au cœur du noyau. Une des raisons principale est que Linux est compilé pour des architectures qui ne sont aujourd’hui pas supportées par Rust.
En plus, réécrire le noyau entier serait contre productif vu l’ampleur du projet.


yannickta Abonné
Le 16/12/2022 à 21h 35

Vu l’immensité de la tache, est-ce seulement souhaitable ? Je préférerais que le jus de cerveau soit utilisé a des choses style migration vers une architecture micro-noyau, par exemple…


esver Abonné
Le 17/12/2022 à 10h 22

100% je pense que ce ne sera jamais le cas, il y aura sûrement toujours des init de processeurs ou autre en assembleur.


mLzz Abonné
Le 16/12/2022 à 08h 06

Merci pour le sous titre, j’ai bien ri :D !
Et merci pour l’article au passage :)


Wosgien Abonné
Le 16/12/2022 à 09h 03

Ghimo a dit:


Bien que le language continue de mûrir, peut-on envisager que le kernel puisse passer à 100% en Rust à moyen / long terme ?




Je crois que la question ne peut pas être résolue ici pour le moment :)



Je ne suis pas sûr que rust soit porté sur toutes les architectures existantes de linux (d’où j’imagine le frontend rust pour gcc)


Le 16/12/2022 à 10h 49

Ghimo a dit:


Bien que le language continue de mûrir, peut-on envisager que le kernel puisse passer à 100% en Rust à moyen / long terme ?




Je pense que c’est l’idée oui.


Le 16/12/2022 à 12h 44

Wosgien a dit:


A priori, ça va aller de plus en plus vite.
Rust est un vrai langage, bien pensé, qui prend en compte les problématiques et opportunités actuelles.




Ca va même trop vite à mon sens. Y a beaucoup de gens qui semblent vouloir adopter ce langage de façon virale parce que c’est tendance et que ca vend du rêve en matière de sécurité.



Pour moi c’est surtout un langage de niche. Il n’a d’intérêt que pour ceux qui cherchent le triptyque “haute-performance” + “memory-safe” + “typage fort façon C”.



C’est donc un langage de spécialiste pour des utilisation spéciales: du code sensible (crypto ?), du bas-niveau (drivers ?).


Wosgien Abonné
Le 16/12/2022 à 13h 43

(quote:2110708:127.0.0.1)
Ca va même trop vite à mon sens. Y a beaucoup de gens qui semblent vouloir adopter ce langage de façon virale parce que c’est tendance et que ca vend du rêve en matière de sécurité.




Ca va dans ton sens: l’adoption est grande parce que RIEN ne pouvais remplacer le C jusqu’à RUST
C’est quasi non exagéré.
Ca grinçait pas mal des dents sur certaines extensions du C qui se mariaient mal à la syntaxe.



Pour le moment, il ne vent pas du rêve. Aucune faille “classique” n’a été trouvée dans la partie BT de Android 11 ou les morceaux linux réécris.




Pour moi c’est surtout un langage de niche. Il n’a d’intérêt que pour ceux qui cherchent le triptyque “haute-performance” + “memory-safe” + “typage fort façon C”.




C’est plutôt vrai. Pour l’embarqué récent, il a aussi son intérêt, pour l’embarqué ancien c’est plus discutable.
Toutefois il intègre de quoi rapidement faire un serveur web, donc pour du microservice web il est bien aussi.




C’est donc un langage de spécialiste pour des utilisation spéciales: du code sensible (crypto ?), du bas-niveau (drivers ?).




Il n’y a pas vraiment de langage “généraliste” à l’aise partout. Je crache abondamment sur python, mais pour le maquettage il est classe quand même. Javascript a des forces, mais il est totalement incomplet et en appui de technos pondues par des schizos avec une bonne dose de guerre mercantile (HTML/CSS), ce qui fait qu’il n’a pas un socle super génial…



C# et Java sont d’excellents compromis, mais quelquesoit le taf sur les garbage collector, c’est difficile d’être “déterministe” sur le temps d’exécution quelque soit le jeu de données en entrée…



Rust a quand même 12 ans de maturation pour cette consécration. Je m’y suis intéressé 3 fois, et cette dernière fois m’a vraiment plû: j’ai réécris un outil de détection de fichiers en doublons en une après-midi, avec de l’asynchrone dedans, et c’est tout petit une fois compilé!
(en gros ça m’a fait l’effet de la découverte de Delphi 3 en 1997: un produit juste “comme ça doit être”)


Le 17/12/2022 à 00h 53

Désolé de vous embêter, la Team, mais je ne comprends pas en quoi mon commentaire était trollesque ou incitait au troll : j’exprimais simplement, sous la forme d’une plaisanterie, ma sincère indignation au fait que Mozilla a abandonné XUL, et ma crainte, tout aussi sincère, que RUST subisse le même sort…



…En quoi est-ce trollesque ?



En d’autres termes : qu’est-ce qui garanti que ce langage, rempli d’un tel potentiel qu’il est intégré dans le noyau Linux (et je m’en réjouis !), ne sera pas à son tour brusquement abandonné dans une poignée d’années, comme le fut XUL ?



Perso, cela fait un bail que je me raccroche à des navigateurs basé sur des anciennes versions de Firefox : Basilisk, Palemoon, Waterfox-classic…



(Regrettant, à chaque fois que je me connecte, que ce site ne fonctionne plus avec cette “vieille” techno… Obligé de me coltiner la toute dernière version de FF que je déteste…)



Pourquoi ? Parce que j’estime que Firefox a non pas évolué, mais bel et bien sévèrement régressé en fonctionnalité : qu’est-ce qui va remplacer mes bien-aimés DownThemAll, Add Bookmark Here, Speed Dial (Josep del Rio)… et tout un tas d’extensions dont je vous épargne la longue liste, et qui ne marchent plus sous les dernières versions de FF ?



(Et ne me parlez pas de leur supposé équivalent “moderne” sous forme de web extension, quelle plaisanterie !…)


GruntZ Abonné
Le 17/12/2022 à 07h 39

(quote:2110833:DantonQ-Robespierre)
En d’autres termes : qu’est-ce qui garanti que ce langage, rempli d’un tel potentiel qu’il est intégré dans le noyau Linux (et je m’en réjouis !), ne sera pas à son tour brusquement abandonné dans une poignée d’années, comme le fut XUL ?




Même si ça ne garanti rien à 100%, le fait qu’il soit géré par une fondation multi-parties le rend plus apte à traverser le temps qu’un outil porté par une entreprise isolée.



PS : moi aussi, je regrette l’ancien Firefox pour quelques extensions irremplaçables (puisque irremplacées) telles que FireSSH et FireFTP.


ericse Abonné
Le 17/12/2022 à 09h 39

(quote:2110833:DantonQ-Robespierre)
En d’autres termes : qu’est-ce qui garanti que ce langage, rempli d’un tel potentiel qu’il est intégré dans le noyau Linux (et je m’en réjouis !), ne sera pas à son tour brusquement abandonné dans une poignée d’années, comme le fut XUL ?




Simplement le fait qu’il soit repris par d’autres. Dans le monde open source ce que le créateur fait de sa création importe moins que sa reprise par d’autres.


ashlol Abonné
Le 17/12/2022 à 15h 31

excellent sous titre même s’il était facile il en reste pas moins parfais
concernant le rust je ne l’ai pas essayé moi même donc je ne peux en dire d’avantage mais il m’a été chaudement recommandé par plusieurs sources et sa reprise dans linux ne fait que confirmer son potentiel.


Uther Abonné
Le 17/12/2022 à 16h 32

Ghimo a dit:


Bien que le language continue de mûrir, peut-on envisager que le kernel puisse passer à 100% en Rust à moyen / long terme ?




A très long terme, tout est possible mais il n’y a rien dans les plan actuels pour aller au delà des drivers. Changer le coeur du noyau serait quelque chose de complexe avec d’énormes disques de régression, et plus le Rust n’est pas disponible sur beaucoup d’architecture supportées pas Linux. Franchement je ne suis pas sur que ça serait une bonne idée, malgré tout mon amour du Rust.




(quote:2110708:127.0.0.1)
Ca va même trop vite à mon sens. Y a beaucoup de gens qui semblent vouloir adopter ce langage de façon virale parce que c’est tendance et que ca vend du rêve en matière de sécurité.



Pour moi c’est surtout un langage de niche. Il n’a d’intérêt que pour ceux qui cherchent le triptyque “haute-performance” + “memory-safe” + “typage fort façon C”.




Rust n’a clairement pas vocation à finir partout, mais il a de l’intérêt au delà de simplement de la sécurité. Il a quand même pas mal de fonctionnalités d’abstraction bien plus avancées.




(quote:2110833:DantonQ-Robespierre)
Désolé de vous embêter, la Team, mais je ne comprends pas en quoi mon commentaire était trollesque ou incitait au troll : j’exprimais simplement, sous la forme d’une plaisanterie, ma sincère indignation au fait que Mozilla a abandonné XUL, et ma crainte, tout aussi sincère, que RUST subisse le même sort…




La situation de XUL et Rust n’est pas vraiment comparable. XUL a toujours été une techno interne a Mozilla pour son propre navigateur et qui n’a pas pris au delà. Alors que Rust, s’il a bien été créé par Mozilla, a toujours été un projet séparé de Firefox qui a vite trouvé sa place en dehors de l’écosystème de Mozilla. Mozilla n’a quasiment plus aucune participation au développement du langage depuis des années, et plus aucun pouvoir décisionnaire. Le développement est communautaire et géré par des groupes de travail indépendants depuis avant sa sortie officielle en 2015. Il a sa propre fondation depuis deux ans.


jb07 Abonné
Le 17/12/2022 à 18h 56

(quote:2110708:127.0.0.1)
Pour moi c’est surtout un langage de niche. Il n’a d’intérêt que pour ceux qui cherchent le triptyque “haute-performance” + “memory-safe” + “typage fort façon C”.




Quand je pense typage fort, le dernier langage qui me vient à l’esprit, c’est le C (quel langage fait pire, à part l’assembleur ?). Après, Rust, je ne connais pas, je ne peux rien dire ; mais si on veut un vrai typage fort, je n’ai encore rien vu de mieux qu’Ada.


grsbdl Abonné
Le 17/12/2022 à 21h 03

A noter qu’aujourd’hui, on intègre toujours plus de code C que Rust. Donc même si ce dernier fait une entrée remarquée dans le noyau Linux, il reste minoritaire, même dans les contributions.
La situation pourrait changer à long terme, mais vu la quantité astronomique de code existant, sa complexité, et compte tenu de l’organisation du développement du noyau (ce n’est pas un produit développé par une entreprise qui, elle, peut dicter des règles et imposer des objectifs, comme par exemple migrer des composants sur Rust), tout dépendra de la volonté des contributeurs, et donc du sex appeal de Rust auprès d’eux.
Si l’on donnait des millions ou des milliards à la Linux Foundation, peut être aurait-on les moyens de migrer bcp de code très vite. Mais est-ce seulement souhaitable ?


SebGF Abonné
Le 18/12/2022 à 09h 13

grsbdl a dit:


Si l’on donnait des millions ou des milliards à la Linux Foundation, peut être aurait-on les moyens de migrer bcp de code très vite. Mais est-ce seulement souhaitable ?




Pluzun, c’est la vraie question à se poser.



N’étant pas développeur, je ne saurais pas me prononcer sur les apports, différences, et intérêts de chacun. Cependant, j’ai assez de recul dans l’IT pour savoir qu’adopter une techno par effet de mode et non parce que ça répond à une problématique n’amène jamais rien de bon.



Un besoin = une solution, et non l’inverse :D


Spike Abonné
Le 18/12/2022 à 11h 06

:yes:



Trop souvent oublié !!!


Spike Abonné
Le 18/12/2022 à 11h 11

Par contre ayant déjà codé en fortement typé (C, C#) et pas du tout typé (Javascript, Php), je ne saisie pas vraiment la difficulté de certains avec le codage typé, je ne serais pas contre une explication de la raison de cette difficulté ? :keskidit:


Le 18/12/2022 à 13h 20

(reply:2110842:GruntZ) (reply:2110856:ericse) (reply:2110907:Uther) <



Merci pour vos réponses, et aussi pour tous les autres commentaires instructifs.



Le 18/12/2022 à 13h 30

( Pardon pour le HS, note au webmaster : je n’arrive pas à mettre à la ligne proprement après un ou plusieurs “reply:xxxxx:username”, on dirait qu’il manque un < p > < /p > ou même un simple < br > après la commande…



Comme vous le voyez dans mon commentaire ci-dessus, il devrait y avoir une mise à la ligne, ou même plusieurs, après la pastille Uther… )



(Pardon pour le HS)


Myddrin Abonné
Le 19/12/2022 à 04h 35

Le rust est beaucoup plus typé que le C, pas de convention implicite en rust! Je n’ai que bidouillé en rust (et que l’advent of code) et la principale différence a été le paradigme de gestion des variables. C’était un vrai challenge d’implémenter quelques lignes qui auraient étaient super simples en C ou python. Malheureusement je n’ai aucune raison de l’utiliser professionnellement (aller, peut-être en back-end d’un micro service mais je suis le seul potentiellement intéressé de l’équipe).


Inodemus Abonné
Le 19/12/2022 à 14h 55

jb07 a dit:


Quand je pense typage fort, le dernier langage qui me vient à l’esprit, c’est le C (quel langage fait pire, à part l’assembleur ?)




Javascript, PHP, Python…




Nicky5 a dit:


Par contre ayant déjà codé en fortement typé (C, C#) et pas du tout typé (Javascript, Php), je ne saisie pas vraiment la difficulté de certains avec le codage typé




Pour ma part c’est l’inverse, c’est avec les langages non typés que j’ai du mal, j’ai l’impression que les en-têtes de fonction ne servent à rien et que sans la doc tu ne sais pas quoi passer à du code que tu n’a pas écrit. Même lire le code derrière (quand on peut) ne m’aide pas vraiment, souvent il appelle juste d’autres fonctions dont je ne sais pas ce qu’elles attendent.



Parce qu’au final il faut toujours des conventions quand on passe des données entre 2 bouts de code séparés, le fait de ne pas avoir les types ne peut qu’être handicapant en faisant croire qu’on peut passer un peu n’importe quoi, sauf qu’évidemment non. En plus il faut aller jusqu’à l’exécution pour savoir si ça passe.


Spike Abonné
Le 19/12/2022 à 16h 21

C’est pas faux :ouioui:


donutboy63 Abonné
Le 20/12/2022 à 10h 08

TYpeScript comble cette lacune pour javascript