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 :
Envoyé par Linus Torvalds
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 ».
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é :
Envoyé par Critique
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.
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 
