Discussion :

[Mathis Lucas]

Linus Torvalds est de plus en plus frustré par le matériel bogué et les attaques théoriques du processeur
dont les mesures d'atténuation peuvent avoir un impact sur la sécurité et l'efficacité du noyau Linux

Linus Torvalds, le créateur de Linux, s'est montré très critique à l'égard des fabricants de matériel lors d'une récente discussion sur la liste de diffusion du noyau Linux. Il a exprimé sa frustration quant à l'utilisation de la macro barrier_nospec() dans la copy_from_user(). En effet, la principale préoccupation de Linus Torvalds concerne la lenteur de barrier_nospec() et la surcharge que ces barrières sont perçues comme étant. Toutefois, ses remarques mettent également en évidence une impatience croissante à l'égard du matériel bogué et des attaques théoriques du processeur, qui ont un impact sur la sécurité et l'efficacité du noyau Linux.

Linus Torvalds agacé fustige les fabricants qui livrent du matériel bogué

Linus Torvalds, créateur de Linux, a participé récemment à un fil de discussion portant sur la possibilité d'éviter d'utiliser barrier_nospec() dans la fonction copy_from_user(). Lors des échanges, Linus Torvalds a déclaré que l'utilisation de cette macro a un impact négatif sur les performances du noyau. La conversation a évolué vers des discussions sur le comportement du processeur et la meilleure façon de le gérer, les différents comportements/exigences avec les nouveaux CPU Intel supportant le Linear Address Masking (LAM), et les maux de tête généraux autour des atténuations de la sécurité du CPU.

Linus Torvalds a indiqué que certains codes suggérés ne fonctionnent probablement pas pour les CPU Intel avec LAM comme Arrow Lake et Lunar Lake. Cependant, en l'absence de certitude sur le comportement de certains processeurs, il a été suggéré de modifier préventivement certains codes du noyau. C'est là que Linus Torvalds a écrit une réponse tard dans la nuit. Il n'a pas hésité à fustiger les fabricants de matériel dans un style classique qu'on lui connaît :

Honnêtement, j'en ai assez du matériel bogué et des attaques complètement théoriques qui n'ont jamais été utilisées dans la pratique.

Je pense donc que cette fois-ci, nous allons faire pression sur les responsables du matériel et leur dire que c'est *LEUR* foutu problème, et s'ils ne peuvent même pas se donner la peine de dire oui ou non, nous nous contenterons de nous asseoir sur nos lauriers.

Parce que bon sang, mettons la responsabilité là où elle se trouve, et ne nous contentons pas de prendre n'importe quelle merde aléatoire d'un mauvais matériel et de dire « oh, mais ça *pourrait* être un problème ».

Linus Torvalds appelle en effet les fabricants de matériels à s'impliquer davantage dans la sécurité du noyau Linux. Après les commentaires de Linus Torvalds, l'ingénieur d'Intel Kirill Shutemov a fait un commentaire sur ce fil de discussion : « LAM apporte ses propres problèmes de spéculation qui seront résolus par LASS. Il y avait un correctif pour désactiver LAM jusqu'à l'arrivée de LASS, mais il n'a jamais été appliqué pour une raison quelconque ».

LASS (Linear Address Space Separation) est une extension de sécurité qui empêche les accès spéculatifs à l'espace d'adressage virtuel entre le mode utilisateur et le mode noyau. Ce code du noyau est un autre sujet que les discussions que Linus Torvalds a eues sur le fait d'éviter barrier_nospec() dans copy_from_user().

Comprendre les critiques de Linus Torvalds à l'égard de barrier_nospec()

La macro barrier_nospec() est une barrière qui empêche les instructions qui la suivent d'être exécutées de manière spéculative. Son utilisation vise à sécuriser les systèmes contre des attaques qui exploitent les vulnérabilités des processeurs, sans compromettre les performances et les solutions de sécurité plus lourdes. Toutefois, Linus Torvalds a décrit l'utilisation de barrier_nospec() comme étant « excessive » dans une récente réponse à une liste de diffusion.

Linus Torvalds a également qualifié l'utilisation de barrier_nospec() de « douloureusement lente ». En effet, les performances peuvent être affectées par l'introduction de barrières d'exécution spéculative pour atténuer les vulnérabilités de type Spectre découvertes dans les processeurs modernes. Ces barrières ont été conçues pour stopper les attaques spéculatives, mais elles peuvent provoquer des temps de latence et réduire l'efficacité des opérations du noyau.

Cela peut entraîner un ralentissement des temps de réponse du système et une baisse des performances pour les utilisateurs finaux, en particulier lorsque ces derniers utilisent des environnements à forte capacité de calcul. Linus Torvalds semble particulièrement contrarié par l'application de mesures d'atténuation sans en comprendre la nécessité dans des cas spécifiques. La sécurité est essentielle, mais les solutions doivent être proportionnées au risque.

Cela ne s'applique pas toujours aux barrières d'exécution spéculative. La macro barrier_nospec() pourrait être appliquée universellement pour protéger contre certaines attaques, mais cela aurait un coût en matière de performances.

Importance de ces questions pour les administrateurs Linux

Le matériel défectueux pousse les développeurs du noyau à prendre des mesures pour atténuer les attaques théoriques du processeur. Mais l'introduction de mesures de sécurité peut dégrader les performances du noyau Linux et avoir un impact direct sur l'expérience de l'utilisateur final et sur la possibilité d'exécuter des applications gourmandes en ressources. Dans les commentaires, beaucoup sont d'avis avec les critiques de Linus Torvalds à l'égard des fabricants.

« Les fabricants de processeurs devraient être poursuivis pour les dommages causés par la mise sur le marché de produits défectueux et dangereux », a écrit l'un d'entre eux. Un autre critique a souligné : « Linus Torvalds a raison à 100 %. Et bien sûr, Intel est à blâmer ». Les critiques appellent Intel, AMD et les autres fabricants de processeurs à améliorer leurs pratiques en matière de sécurité. D'autres commentateurs affichent toutefois un sentiment mitigé :

Je suis presque certain que les attaques par canal latéral de la synchronisation du cache étaient une curiosité théorique, jusqu'à ce que soudainement, très soudainement, elles ne le soient plus et que quelqu'un démontre qu'il est possible de s'emparer de clés privées entre des machines virtuelles isolées fonctionnant sur une même machine.

Le problème avec les attaques théoriques, c'est qu'on ne sait jamais quand elles deviennent non théoriques et qu'elles peuvent se transformer très rapidement en vulnérabilités zero-day très désagréables.

La compréhension des compromis au sein du noyau permet aux administrateurs de prendre des décisions éclairées sur les configurations et les versions du noyau qui conviennent à des cas d'utilisation spécifiques. Pour maintenir un haut niveau de sécurité, ils doivent être au courant des discussions les plus récentes sur la sécurité du noyau. Comprendre le raisonnement qui sous-tend certaines mesures d'atténuation permet de mieux évaluer les risques.

Selon les experts, cela permet de hiérarchiser les mises à jour et les configurations en fonction de la tolérance au risque de l'organisation. L'instabilité peut également être causée par les changements fréquents du noyau nécessaires pour corriger les vulnérabilités matérielles. Les administrateurs doivent être attentifs aux mises à jour et les tester minutieusement dans des environnements d'essai avant de les déployer sur les systèmes de production.

Quelques solutions potentielles pour résoudre ces défis

La sécurité et les performances sont constamment en conflit au sein du noyau Linux. Selon les experts, cette tension nécessite des solutions immédiates et à long terme. Une première approche pourrait consister à appliquer les barrières d'exécution spéculative de manière sélective plutôt que de manière universelle. Cela ne concernerait que les processus traitant des données sensibles ou les systèmes qui présentent un risque d'attaque plus élevé. Les administrateurs peuvent ajuster les paramètres du noyau pour équilibrer les performances et la sécurité en fonction des besoins opérationnels.

Une meilleure collaboration entre la communauté des développeurs de noyaux et les fabricants de matériel peut déboucher sur un silicium plus efficace, réduisant ainsi la nécessité de recourir à des logiciels d'atténuation. Les projets open source qui sont plus transparents et coopèrent avec les fabricants peuvent aboutir à des mesures d'atténuation plus adaptées et plus efficaces.

Les développeurs peuvent également optimiser l'impact des correctifs sur les performances et affiner les barrières d'exécution spéculative afin de minimiser les frais généraux tout en conservant leurs avantages en matière de protection. Dans ce processus, les analyses comparatives et les tests de performance sont essentiels.

L'utilisation d'une modélisation plus sophistiquée des menaces, qui évalue à la fois la faisabilité et l'exploitabilité des attaques théoriques, peut aider à élaborer une stratégie d'atténuation plus équilibrée. Les développeurs peuvent mieux évaluer les risques dans le monde réel et donner la priorité aux efforts qui apporteront les avantages les plus importants en matière de sécurité tout en ayant une solution avec un impact négligeable sur les performances.

En mettant en œuvre des configurations de noyau plus dynamiques, les systèmes peuvent ajuster leur posture de sécurité en temps réel en fonction de l'environnement de menace actuel. Cela permet de renforcer les protections lorsque le niveau de menace est élevé et d'assouplir ces protections lorsque le niveau de menace diminue.

Il est possible d'obtenir différentes perspectives en encourageant un niveau de participation plus important dans les discussions sur le développement du noyau. Cette méthode axée sur la communauté peut créer des mesures d'atténuation efficaces et efficientes en s'appuyant sur différents domaines d'expertise.

Sources : Linus Torvalds, Kirill Shutemov, ingénieur d'Intel

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous des critiques de Linus Torvalds à l'égard des fabricants de matériels ?
Ses critiques sont-elles fondées ? Comment la communauté peut-elle venir à bout de ces problèmes ?
Que pensez-vous des impacts négatifs des barrières d'exécution spéculative sur les performances du noyau Linux ?

Voir aussi

Linus Torvalds est frustré par le problème persistant de saccade du module fTPM d'AMD et propose de désactiver ce truc "stupide", il estime que le module nuit aux performances du noyau Linux

Linus Torvalds estime que l'architecture 80486 appartient à un musée, pas au noyau Linux. Selon lui, le matériel ancien ne peut pas justifier la consommation du temps précieux des développeurs

Linus Torvalds fustige un contributeur de Google au noyau Linux pour ses suggestions relatives aux inodes des systèmes de fichiers, il a qualifié de "déchet" un code soumis par le Googler

[LittleWhite]

Linus Torvalds est de plus en plus frustré par le matériel bogué et les attaques théoriques du processeur

Moi aussi ! (mais on s'en fout)

[eomer212]

je me rappelle d'une époque, l'époque "bénie" (j'étais jeune, beau, et je le suis toujours dans ma tête) ou n'y avait pas de coprocesseur, et ou il fallait comprendre comment calculer un sinus à partir d'entiers en assembleur.
bref, on devait ramer comme des malades pour sortir les processeurs et les cartes graphiques vga de leur létargie. il fallait comprendre le materiel, et en particulier le processeur, son fonctionnement et ses limites. qu'on pouvait éventuellement dépasser, par la ruse et l'intelligence.
une des astuces existantes était le déroulé de code.
on déroule des fonctions qui auraient du faire un saut pour boucler, pour éviter le plus possible les branchements qui brisent la prédiction ou le pré chargement de code du processeur.
c'est con, c'est basique, et c'est très, très efficace.
moi je dis ca. mais bon, je peux me tromper, mais je pense que ca doit encore marcher..
en passant, un petit coucou extrêmement révérencieux à Mr Torvald, à qui nous devons tous beaucoup.

[JP CASSOU]

Ne parlons pas des sites, applis et logiciels bogués et inutilisables

De plus en plus complexes, lourds, lents, bogués et au final inutilisables au quotidien, au point qu'un acte d'achat ou une transaction avec l'internet actuel prend 5x plus de temps qu'une opération à la finalité identique effectuée avec le Minitel des années 1980.

Faudrait peut-être penser à faire un "gel des technologies" et arrêter de concevoir 40.000 frameworks, 2.500 langages de programmation et 38 tonnes de librairies.

Le 64 bits grand public existe depuis le début des années 2000.

Nous avons des applications métier dont on ne se sert pas (ou plus) étant donné leur lenteur et lourdeur au point de rendre les procédures manuelles plus rapides et fiables

[petitours]

Ne parlons pas des sites, applis et logiciels bogués et inutilisables

De plus en plus complexes, lourds, lents, bogués et au final inutilisables au quotidien, au point qu'un acte d'achat ou une transaction avec l'internet actuel prend 5x plus de temps qu'une opération à la finalité identique effectuée avec le Minitel des années 1980.

Faudrait peut-être penser à faire un "gel des technologies" et arrêter de concevoir 40.000 frameworks, 2.500 langages de programmation et 38 tonnes de librairies.

Le 64 bits grand public existe depuis le début des années 2000.

Nous avons des applications métier dont on ne se sert pas (ou plus) étant donné leur lenteur et lourdeur au point de rendre les procédures manuelles plus rapides et fiables

+1
L’évolution des "technos", avec des châteaux de carte compatibilités douteuses et tout cloud servent depuis une bonne 15n d'année uniquement des objectifs de captage client qui ne peut plus regarder un truc sans échapper à la pub, ou faire quelquechose sans laisser un log ou tout simplement plus disposer des données qu'il a envoyé sur une plateforme ou dans le cas des films qu'il a acheté, obligé de rester là, soumis à son prestataire pour continuer à profiter de ce qu'il a déjà acheté et le tout en se faisant assommer de pub ciblées par les données qu'il n'a pas voulu donner même s'il a évidement coché la 5ieme case en partant de la gauche sans quoi le bouton n’apparaissait pas.
Je trouve ça extrêmement frustrant de voir autant de moyens techniques et d'énergie mobilisée pour des services qui assurent de moins en moins la fonctionnalité de base.

Exemple hier soir, et de plus en plus fréquent. Je regarde un film en replay en me payant des tas de pubs (inutiles puisque elles créent en moi un profond rejet) et paf, erreur technique qui s'affiche à 20 min de la fin. On pourrait s'interroger sur la nécessiter d'une liaison internet et d'un serveur surpuissant pour simplement regarder un film mais j'ai surtout mis une bonne demie heure à retrouver là où j'en étais dans le film, car l'avance rapide était non seulement buguée à revenir sans arrêt à 0 mais en plus ça s’arrêtait à chaque période de pub pour me la passer en intégralité. L'appli c’était la pub au service du fournisseur, à la base ça sert à regarder des films, ça ne sait plus faire.

Tu achètes un film, tu ne peux pas le télécharger
Tu achètes de la musique ou le même film, tu as besoin d'une connexion internet et de continuer à payer la plateforme pour voir et écouter ce que tu as déjà acheté

[Jules34]

Je trouve ça extrêmement frustrant de voir autant de moyens techniques et d'énergie mobilisée pour des services qui assurent de moins en moins la fonctionnalité de base.

Disons que la technologie n'est pas mise au service des individus mais du marché et de ses attentes.

Ce qui fait que le marché ET la technologie finiront par faire l'objet d'un rejet massif, personne n'aime les pubs, personne n'aime être ciblé et surtout personne n'aime être pris pour un abruti... tout en payant pour ses services.

[floyer]

Dans l’exemple, le replay, c’est gratuit donc c’est toi le produit. Si tu regardes Netflix, il ok, c’est payant mais tu n’as pas de pub. Dans un marché bien fait, tu aurais une offre Premium sans pub.

Bon, le replay gratuit c’est un peu faux… les opérateurs payent les chaînes pour diffuser ce qui est gratuit via la TNT. (Mais en échange, il me semble qu’ils ont droit à une TVA moindre).

[Uther]

Dans l’exemple, le replay, c’est gratuit donc c’est toi le produit. Si tu regardes Netflix, il ok, c’est payant mais tu n’as pas de pub. Dans un marché bien fait, tu aurais une offre Premium sans pub.

Bon, le replay gratuit c’est un peu faux… les opérateurs payent les chaînes pour diffuser ce qui est gratuit via la TNT. (Mais en échange, il me semble qu’ils ont droit à une TVA moindre).

Netflix est payant, mais il ne faut pas croire que tu n'es pas aussi un produit. Tes habitudes de visionnage sont judicieusement étudiées.

[petitours]

Dans l’exemple, le replay, c’est gratuit donc c’est toi le produit.

Tu es le produit mais pour que ce soit gratuit il faudrait que ce soit un service hors ça n'en est pas puisqu'il est pour bon nombre de chaine la modeste compensation à la perte de possibilité d'enregistrer.
Ils se font le beurre, la crémière et ont oublié de laisser le pain.

[JP CASSOU]

et le tout en se faisant assommer de pub ciblées par les données qu'il n'a pas voulu donner même s'il a évidement coché la 5ieme case en partant de la gauche sans quoi le bouton n’apparaissait pas.

D'un Internet ouvert des débuts, on en est arrivé à un Web fermé de toutes parts et un Net-poubelle:
- Obligation de créer un compte par site, ou pas loin
- Paywalls et cookieswalls, surtout les "Refuser et s'abonner"
- Pub omniprésente
- Résultats de recherche non pertinents
- Sites marchands qui t'imposent de remplir un formulaire de 50 champs pour connaître le prix d'un appareil
- 100% des forums sont à inscription obligatoire (corollaire: la V95 d'un forum est de moins de trois mois - La V95 correspond au temps écoulé entre l'ouverture du forum et le moment où 95% des posts ont été publiés)
- 99% des sites web sont obsolètes
- 90% des bannières cookies ne respectent pas le RGPD
- Pour une question technique, les 100 premiers résultats de Google, c'est du publi-rédactionnel
- 80% des sites web et intranets institutionnels (et aussi d'entreprises) ont une disponibilité inférieure à 95%.
- Le nombre de bugs dans les sites Web est proprement ahurissant. Lors de la période 2003 (ADSL chez moi) à 2012 (arrêt du Minitel), je faisais les démarches critiques sur le Minitel. Plus simple, plus rapide (surtout les 36.13 et 36.14 - les autres étant volontairement ralentis) et surtout plus fiable.

Je pense sincèrement qu'il faut repenser complètement le net en ajoutant un protocole sécurisé et simplifié, pour tout ce qui concerne le commerce en ligne, les démarches administratives, les banques et la santé.
Ce protocole devrait avoir les caractéristiques suivantes:
- Mode texte exclusivement
- Accès par authentification à plusieurs facteurs
- Limitation du poids des pages à moins de 200 Ko (sauf téléchargement)
- Utilisable pleinement sur des connexions très lentes
- Fiabilité proche de 100%

Bref, un protocole proche du Minitel ou Gemini (port 1965)
-

[floyer]

À quoi bon créer un nouveau protocole… s’il ne distribue pas la pub, il sera boudé par les créateurs de contenus.

HTTP permet de distribuer du fichier texte… mais si les sites sont plus lourds (HTML, animation, etc…) c’est aussi plus attrayant. Pas sûr qu’un retour au Minitel ait un succès. (Il faut une adhésion des deux côtés). On peut très bien faire un site avec un sous ensemble d’HTML (H1/H2/P/A par exemple). Je note que Stéphane Bortzmeyer semble derrière gemini… mais son blog est déjà très simple en matière de présentation et ne devrait pas poser de problème de fiabilité de consommation de ressources, etc. (Ok pas si simple, le bandeau de navigation ne s’affiche pas sur le smartphone en mode portrait). On peut déjà faire simple avec ce que l’on a !

[air-dex]

Faudrait peut-être penser à faire un "gel des technologies" et arrêter de concevoir 40.000 frameworks, 2.500 langages de programmation et 38 tonnes de librairies.

Faudrait surtout choisir les technologies en fonction de leur aptitude à résoudre les défis posés plutôt qu'en fonction des CVs que le prestataire a à vendre.

L'appli c’était la pub au service du fournisseur, à la base ça sert à regarder des films, ça ne sait plus faire.

Ça me rappelle cette vieille BD de CommitStrip : https://www.commitstrip.com/fr/2016/...re-roll-video/

C'est plus vraisemblablement une appli servant à diffuser de la publicité car c'est grâce à ça qu'elle rapporte de l'argent. Du coup j'ai envie de dire qu'elle sait très bien faire ce qu'elle fait.

[Mathis Lucas]

Le mélange de Rust et de C dans Linux est assimilé à un « cancer » par un responsable du noyau
« je ne veux pas qu'il s'approche d'une énorme base de code C que je dois maintenir », dit-il à propos de Rust

L'intégration du langage Rust dans le noyau Linux continue de créer des divergences d'opinions dans le rang des mainteneurs. Certains voient en Rust une opportunité d'améliorer la sécurité et la robustesse de Linux, notamment grâce à sa gestion de la mémoire et à sa prévention des erreurs courantes en C. D'autres expriment des réserves, soulignant la complexité du langage et les risques liés à son adoption dans un projet aussi vaste que Linux. Un responsable du noyau, Christoph Hellwig, s'est récemment opposé à l'intégration d'un correctif écrit en Rust dans le noyau, indiquant clairement qu'il n'est tout simplement pas intéressé par le code Rust.

Rust for Linux : une initiative qui provoque des divisions dans la communauté du noyau

Le projet Rust for Linux vise à intégrer le langage de programmation Rust au sein du noyau Linux, historiquement écrit en C et en assembleur. Lancé en 2020, ce projet a pour objectif principal de tirer parti des garanties de sécurité mémoire offertes par Rust afin de réduire les bogues et vulnérabilités dans le développement des pilotes du noyau. Toutefois, bien que le projet soit jugé prometteur, il semble que les choses ne se passent pas comme prévu.

Certains craignent que la multiplicité des langages rende plus difficile la maintenance de ce super-projet open source, d'autres ne sont pas d'accord. Et aujourd'hui, les développeurs qui tentent d'ajouter du code Rust au noyau Linux se heurtent à l'opposition des responsables du noyau. Certains responsables du noyau estiment notamment que l'utilisation de plusieurs langages est une « complication indésirable et risquée ». C'est le cas de Christoph Hellwig.

Des inquiétudes sont apparues en août 2024 lorsque l'ingénieur logiciel de Microsoft Wedson Almeida Filho s'est retiré du projet Rust for Linux, citant sa frustration face à des « absurdités non techniques », ce qui est une façon de décrire la difficulté de collaborer avec ceux qui ont des objectifs différents.

Le problème s'est à nouveau posé en janvier 2025, lorsqu'une proposition d'abstraction permettant aux pilotes de périphériques écrits en Rust d'appeler l'API DMA de Linux principalement basé sur le langage C s'est heurtée à l'opposition ferme de Christoph Hellwig, un responsable du noyau.

Plus précisément, un contributeur du noyau a soumis un correctif pour permettre aux pilotes Rust d'utiliser la fonction C dma_alloc_coherent() de l'API DMA afin d'allouer et de faire correspondre de grandes zones de mémoire pour un accès direct à la mémoire. Christoph Hellwig s'est opposé à ce correctif.

Dans un message adressé à la liste de diffusion du noyau Linux, Christoph Hellwig a écrit : « pas de code Rust dans kernel/dma, s'il vous plaît ». Par la suite, Miguel Ojeda, le développeur principal du projet Rust for Linux, a demandé à Christoph Hellwig de suggérer une alternative.

Christoph Hellwig : « ne me forcez pas à travailler avec votre langage brillant du jour »

En adoptant Rust, la communauté autour du noyau Linux devrait mettre à profit les atouts du langage sur le C. Et elle devrait faire d’une pierre deux coups, étant donné que Rust peut faciliter l’arrivée de nouveaux contributeurs. C’est en tout cas ce que laisse entrevoir une étude de l’université de Waterloo. Mais les habitués du langage C désapprouvent l'initiative et n’entendent pas se laisser embarquer dans ce qu’ils appellent la nouvelle religion du Rust.

En réponse à Miguel Ojeda, Christoph Hellwig a déclaré : « gardez les wrappers dans votre code au lieu de rendre la vie difficile aux autres », et a poursuivi en affirmant que « les interfaces de l'API DMA devraient rester dans un code C lisible et non dans des bindings bizarres afin qu'il [reste] greppable et maintenable ».

Le souhait de Christoph Hellwig semble être que les pilotes qui ne sont pas écrits en C aient leurs propres liaisons privées avec le code C, et que ces abstractions ne soient pas maintenues séparément, pas même dans l'arbre rust/kernel. Interrogé par Danilo Krummrich, un ingénieur logiciel de Red Hat impliqué dans le projet Rust for Linux, Christoph Hellwig a clairement fait savoir qu'il n'est tout simplement pas intéressé par le code Rust :

Ne me forcez pas à travailler avec votre langage brillant du jour. La maintenance de projets multilingues est une tâche pénible à laquelle je n'ai aucune envie de m'atteler. Si vous voulez utiliser quelque chose qui n'est pas du C, que ce soit de l'assembleur ou du Rust, vous écrivez dans des interfaces C et vous vous occupez vous-même du décalage d'impédance en ce qui me concerne.

En réponse, Danilo Krummrich a expliqué que Rust for Linux crée un code Rust qui abstrait les API C pour tous les pilotes Rust et qui est maintenu par les développeurs Rust. En d'autres termes, le côté C du noyau reste le même, et les pilotes Rust utilisent des abstractions de ce code C, et ces abstractions sont maintenues par une équipe centralisée dans rust/kernel, ce qui est sans doute mieux que des pilotes ayant leurs propres bindings C individuels.

Mais Christoph Hellwig ne semble pas intéressé par le fait que les abstractions DMA Rust soient maintenues séparément. Christoph Hellwig a expliqué qu'il ne voulait pas d'un autre mainteneur. Il a poursuivi en affirmant que le fait de demander à d'autres de maintenir la couche d'abstraction Rust pour l'allocateur cohérent DMA en tant que composant séparé n'améliore pas les choses et entrave la maintenabilité du noyau Linux :

Si vous voulez rendre Linux impossible à maintenir à cause d'une base de code interlangage, faites-le dans votre pilote pour que vous ayez à le faire au lieu de répandre ce cancer dans les sous-systèmes centraux. (Où ce cancer est explicitement une base de code interlangage et non Rust lui-même, juste pour échapper à la brigade flameware.)

Chaque bit supplémentaire introduit par un autre langage réduit considérablement la maintenabilité du noyau en tant que projet intégré. La seule raison pour laquelle Linux a réussi à survivre aussi longtemps est qu'il n'a pas de frontières internes, et l'ajout d'un autre langage rompt complètement avec cela.

Vous n'aimerez peut-être pas ma réponse, mais je ferai tout ce qui est en mon pouvoir pour arrêter cela. Ce n'est pas parce que je déteste Rust. Même si ce n'est pas mon langage préféré, c'est certainement l'un des meilleurs nouveaux langages et j'encourage les gens à l'utiliser pour de nouveaux projets là où il convient.

Je ne veux pas qu'il s'approche d'une énorme base de code C que je dois maintenir.

Les remarques de Christoph Hellwig contrastent avec les analyses du créateur de Linux, Linus Torvalds. Il est d'avis que Rust peut aider à corriger des erreurs commises en C. Il pense que Rust est une solution d’avenir pour le développement du noyau. Ainsi, Linus Torvalds considère la prise en charge de Rust pour le développement du noyau Linux comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr ».

Il a déclaré : « le C est, en fin de compte, un langage très simple. C'est l'une des raisons pour lesquelles j'apprécie le C et pour lesquelles beaucoup de programmeurs C apprécient le C, même si le revers de la médaille est évidemment que, parce qu'il est simple, il est aussi très facile de faire des erreurs ».

Les remarques de Christoph Hellwig sont jugées en violation du code de conduite

Hector Martin, chef de projet d'Asahi Linux, estime que « les remarques de Christoph Hellwig constituent une violation du code de conduite », mais doute que des mesures disciplinaires soient prises. Il estime que les développeurs de Rust for Linux devraient ignorer les préoccupations de Christoph Hellwig et soumettre leur correctif à l'approbation du patron du noyau, Linus Torvalds. Selon lui, l'avenir de Rust for Linux dépendra de la réponse de Linus Torvalds.

Si Linus n'apporte pas de réponse officielle à ce fil de discussion, Miguel et les autres développeurs Rust devraient simplement fusionner cette série une fois qu'elle sera revue et prête, en ignorant la tentative manifeste de Christoph de saboter le projet. Si Linus [accepte la pull request], ce que dit Christoph n'a pas d'importance. Si Linus ne l'accepte pas, le projet [Rust for Linux] est essentiellement mort jusqu'à ce que Linus ou Christoph fassent un geste. Tout le reste, c'est tourner autour du pot.

Le 7 février 2025, Hector Martin a demandé à être retiré de la liste des mainteneurs de Linux. « Je n'ai plus aucune confiance dans le processus de développement du noyau ou dans l'approche de la gestion de la communauté », a-t-il écrit dans une note adressée à la liste de diffusion du noyau Linux.

« Le développement de la plate-forme Apple/ARM se poursuivra en aval. Si j'ai envie d'envoyer moi-même des correctifs en amont à l'avenir, pour quelque sous-arbre que ce soit, je le ferai, ou je ne le ferai pas. Tous ceux qui ont envie de se battre en amont eux-mêmes sont les bienvenus », a-t-il ajouté.

Le noyau Linux a ajouté la prise en charge du code Rust le 3 octobre 2022, peu après que Mark Russinovich, directeur technique de Microsoft Azure, a affirmé que les nouveaux projets de programmation devraient être écrits en Rust plutôt qu'en C ou C++. Mark Russinovich a justifié sa position par le fait que le code Rust peut être écrit de manière à éviter les bogues de sécurité de la mémoire (par exemple, les débordements de mémoire tampon).

Ces bogues affectent depuis longtemps le code C et C++ et représentent la majorité des vulnérabilités sérieuses dans les grands projets. Le point de vue de Mark Russinovich a depuis lors attiré le soutien de nombreuses organisations gouvernementales de sécurité dans le monde entier.

Peu après que l'ingénieur logiciel de Microsoft Wedson Almeida Filho a annoncé son départ de Rust for Linux l'année dernière, Linus Torvalds a abordé la question des frictions entre les développeurs C et Rust lors du sommet Open Source de la Fondation Linux à Vienne, en Autriche. « Il est clair que certaines personnes n'aiment pas la notion de Rust et le fait que Rust empiète sur leur domaine », a déclaré Linus Torvalds.

« Les gens ont même dit que l'intégration de Rust était un échec... Nous faisons cela depuis deux ans maintenant, il est donc bien trop tôt pour dire cela, mais je pense aussi que même si cela devenait un échec - et je ne pense pas que ce sera le cas - c'est comme cela que l'on apprend », a-t-il ajouté.

Source : liste de diffusion du noyau Linux (1, 2) ; Christoph Hellwig, responsable du noyau Linux (1, 2) ; Hector Martin, chef de projet d'Asahi Linux (1, 2)

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous des remarques du responsable du noyau Linux sur le code Rust ?
Selon vous, ses remarques violent-elles le code de conduite de la communauté ? Pourquoi ?
Selon vous, pourquoi l'intégration de Rust dans le noyau crée autant de division parmi les mainteneurs ?
Quels impacts les frictions entre les développeurs C et Rust pourraient-ils avoir sur le développement de Linux ?
Les contributeurs au noyau se raréfient. Pensez-vous que l'avenir du noyau Linux dépend de la réussite du projet Rust for Linux ?

Voir aussi

Linus Torvalds s'exprime à nouveau à propos du débat sur le choix entre C ou Rust pour le développement du noyau Linux et laisse entendre que le Rust peut aider à corriger des erreurs commises en C

L'un des responsables de la maintenance du noyau Linux Rust se retire du projet, invoquant des "absurdités non techniques"

Rust dans le noyau Linux: un projet prometteur, mais pas sans complications. La communauté dresse un bilan lors de l'édition 2023 du Kernel Maintainers Summit

[DNABSY]

Avec tout ce ramdam autour de C et de Rust, pourquoi ne pas envisager de développer un nouveau Linux entièrement avec Rust ?

Tout le code Linux serait entièrement migré en Rust (il y a du boulot) et plus d'embrouille avec les mainteneurs en C car plus de contacts avec eux.

Aujourd'hui, ce ramdam risque de ne pas attirer ceux qui font du Rust et qui souhaiteraient malgré tout participer au développement de Linux
=> Nouveau projet en partant du début => Nouvelle motivation => Nouveaux mainteneurs

C'est juste une idée d'un projet à part !

[Mingolito]

Avec tout ce ramdam autour de C et de Rust, pourquoi ne pas envisager de développer un nouveau Linux entièrement avec Rust ?

Tu as oublié de voir la série en totalité, à partir du début depuis l'épisode 1 saison 1.

Linux est encore en vie uniquement grâce à une petite poignée de vieux grabataires pré retraités de plus de 50 ans qui codent en C avec un truc qui s'appelle un clavier.
La nouvelle génération Z qui sait pas coder et qui a obtenu son certificat de codage dans une pochette surprise en faisant ses devoirs grâce à ChatGP ne risque pas de pondre un truc utile comme Linux, même en Rust, même en Basic ils n'en seraient pas capables.
Les entreprises ne veulent plus recruter de juniors car elle savent très bien qu'ils ne valent absolument rien, et encore quand ils se pointent au travail. 37 % des employeurs préfèrent embaucher une IA plutôt qu'un jeune diplômé de la génération Z, les employeurs déplorent le manque de motivation et d'initiative des jeunes diplômés de la génération Z, et des rapports indiquent que les juniors en informatique n'ont pas les compétences techniques requises.

De toute façon la génération Z le codage ça les intéresse pas, ils se disent "super bon en codage et en informatique", des vrais "hackers" parce qu'ils jouent 10 heures par jours à Counter strike.
Voila l'avenir de l'humanité et ceux qui sont censés payer notre retraite : 57 % des membres de la génération Z veulent devenir des influenceurs

Une fois que tous les anciens seront à la retraite, je pense que le monde va mourir

[Invité]

Avec tout ce ramdam autour de C et de Rust, pourquoi ne pas envisager de développer un nouveau Linux entièrement avec Rust ?

Tout le code Linux serait entièrement migré en Rust (il y a du boulot) et plus d'embrouille avec les mainteneurs en C car plus de contacts avec eux.

Parce qu'il faut la coopération des mainteneurs en C pour pouvoir comprendre et migrer leur code en Rust avec succès. Et il faut suffisamment de développeurs Rust pour assurer la maintenance du tout à moyen et long terme. Si c'était uniquement une histoire de code source à convertir syntaxiquement en Rust, il y a très longtemps que ce serait fait.

[fdecode]

pourquoi ne pas envisager de développer un nouveau Linux entièrement avec Rust ?

Il existe différents projets d'OS.
https://www.redox-os.org/
https://docs.tockos.org/kernel/

Des projets universitaires aussi:
https://github.com/hermit-os
https://github.com/theseus-os/Theseus

[fdecode]

Une fois que tous les anciens seront à la retraite, je pense que le monde va mourir

La France n'est pas le monde. L'Europe ou les États-Unis ne le sont pas non plus.

[Invité]

Il existe différents projets d'OS.
https://www.redox-os.org/
https://docs.tockos.org/kernel/

Des projets universitaires aussi:
https://github.com/hermit-os
https://github.com/theseus-os/Theseus

Malheureusement le projet Redox est en version pre-stable (preview) après 10 ans de développement... une trajectoire similaire à celle du projet Hurd, démarré au début des années 90.

[fdecode]

Malheureusement le projet Redox est en version pre-stable (preview) après 10 ans de développement... une trajectoire similaire à celle du noyau Hurd, démarré au début des années 90.

Dans mes souvenirs, Hurd était assez loin d'une version pré-stable en 2000... Mais, je me trompe peut-être. Je m'y suis peu intéressé.
Un OS comme ReactOS met du temps à émerger aussi.

À l'époque des premiers Linux, les utilisateurs étaient prêts à paramétrer eux-même le XWindow au risque de griller leur moniteur (mauvais souvenir pour moi) et se contentaient des 3 disquettes de la slackware.

Je pense que le développement d'un OS (en fait, l'OS + les distributions + les drivers ...) est plus compliqué maintenant.