Linus Torvalds en a « marre » du matériel buggé d’Intel et AMD
Le 23 octobre à 09h01
2 min
Sécurité
Sécurité
Dimanche dernier, Linus Torvalds s’est exprimé vertement contre les multiples problèmes de sécurité rencontrés dans les processeurs. Plus précisément, il dit toute sa frustration face à des attaques théoriques, mais jamais démontrées. Il souhaite que les entreprises concernées prennent leur responsabilité, comme l’a relevé lundi Phoronix.
« Honnêtement, j'en ai vraiment marre du matériel buggé et des attaques complètement théoriques qui n'ont jamais été utilisées en 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 ne bougerons pas.
Parce que bon sang, mettons la responsabilité là où elle se trouve, et ne prenons pas n'importe quelle merde aléatoire d'un mauvais matériel et disons "oh, mais ça pourrait être un problème" », a fustigé Torvalds.
La réaction, vive, faisait partie d’une discussion sur les techniques de protection des processeurs. Kirill Shutemov, ingénieur chez Intel, expliquait ainsi que la technologie LAM (Liner Address Masking, introduite dans les Core de 12e génération), qui masque les pointeurs mémoire des métadonnées, introduisait ses propres risques d’attaques spéculatives. L’ingénieur ajoutait que ces problèmes pouvaient être atténués grâce à LASS (Linear Address Space Separation), qui isole matériellement l’espace d’adressage.
Linus Torvalds veut donc faire pression sur les vendeurs de matériel. Il invite à ne plus réagir sans informations claires de leur part sur la faisabilité concrète de ces attaques potentielles. Le sujet rappelle les problèmes rencontrés par GNU Boot pour prendre en charge le matériel et, plus généralement, les difficultés du libre à obtenir un support complet.
Le 23 octobre à 09h01
Commentaires (15)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 23/10/2024 à 09h12
Modifié le 23/10/2024 à 14h27
From the tests run for this article, the Core i7 7700K and 8700K were seeing around 75% the performance of the unmitigated (mitigations=off) performance (...). With the current generation Intel Core i9 10900K with the same benchmarks is now at just over 95% the unmitigated performance. On the AMD side, with the new Ryzen 9 5950X it's about 90% the unmitigated performance due to the enhanced Zen 3 protections increasing their overhead (...)
Sauf que c'est au point même d'être contre-productif de les désactiver car ça causerait une baisse de perfs sur les Ryzen Zen 4.
Le 23/10/2024 à 14h39
Et pour le coup, le test cryptsetup n'est pas un simple exercice de benchmark mais un cas d'usage fort courant de nos jours surtout avec un SSD NVMe moderne capable de saturer le bus PCIe. On parle bien d'un vrai goulot d'étranglement et pas de qq pourcents perdus uniquement.
Modifié le 23/10/2024 à 15h08
Le 23/10/2024 à 09h18
Le 23/10/2024 à 09h40
Sauf que ça implique de voir si ça ne risque pas de créer un bug sur plein d'autres processeurs etc
Le 23/10/2024 à 10h29
Modifié le 23/10/2024 à 10h22
Le 23/10/2024 à 10h17
Si Ms corrige les Windows, à la fin ce CVE sera affecté à Linux...
Techniquement, c'est depuis spectre une horreur: des mecs (oups, des meufs aussi :) ) bossent sur le noyau ou les compilo pour optimiser à mort, puis une faille sort et tous doivent travailler à combler une faille qui limite les perfs.
Les compilos actuels ont plusieurs mitigations qui "pourrissent" le résultat...
Modifié le 23/10/2024 à 10h49
Après, autant au niveau du noyau que des compilateurs, ces "pourrissements" doivent rester optionnels. On ne devrait les activer qu'à la fois pour les processeurs concernés dans une application à risque dans une situation à risque. Il ne faut pas les activer sans réfléchir et râler ensuite parce que ça se traîne.
Et le gars qui a besoin en même temps de performances et de sécurité maximale, il n'a qu'à pas prendre un CPU foireux et voilà, ou découper son traitement en une partie performante et une partie sécurisée, sur 2 machines différentes si besoin.
Modifié le 23/10/2024 à 11h44
Sauf qu'au moment ou tu achètes, tu ne sais généralement pas encore que le CPU est foireux. Et si tu as investi beaucoup tu ne vas certainement pas le jeter,
Modifié le 23/10/2024 à 13h40
Pour éviter les cpu foireux: ben c'est impossible, tous les cpu sont touchés (y compris risc-v et arm, selon constructeur/modèle)
Par contre dans une VM, il y a possibilité de limiter les instructions dispos.
Le 23/10/2024 à 12h39
Le 23/10/2024 à 12h31
Si on découvre un problème/bug/défaut, il faut remonter le fil et en fin de parcours, modifier les méthodes (ou resserrer des boulons) qui feront que l'on ne repart pas dans le syndrome en boucle.
Au lieu de ça, on patche et basta.
L'industriel préfère risquer plutôt que cela coute plus cher (ou que cela prenne plus de temps).
Le 23/10/2024 à 14h12