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...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
