Connexion
Abonnez-vous

Linus Torvalds en a « marre » du matériel buggé d’Intel et AMD

Linus Torvalds en a « marre » du matériel buggé d’Intel et AMD

Le 23 octobre à 09h01

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.

Abonnez-vous
votre avatar
Bah c'est clair que ça fout les boules d'acheter du matos récent et de voir son bus IO divisé par 2 (et de tout ce qui va avec notamment les périph PCI) à cause de toutes les mesures de sécurité. Du coup perso tous mes linux ont un mitigations=off.
votre avatar
Le gain dépend du matériel utilisé :

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.
votre avatar
Attention aux tests de Phoronix qui sont généralement très orientés CPU exclusivement. Par exemple dans le benchmark que tu cites, un des tests les plus intéressants relatifs au bus IO que j'évoquais est le test cryptsetup (page 4) et on voit un certain de nombre de résultats qui sont effectivement proches des 50%. J'ai fait le test sur du Zen 3 avec fio et j'obtenais les mêmes résultats.

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.
votre avatar
Merci je ne connaissais pas cette limite logicielle.
votre avatar
J'ai pas compris de quoi il se plaint ? Est-ce que les "fournisseurs de materiel buggué" lui demandent de faire quelque chose (à lui et/ou à Linux) pour y pallier ?
votre avatar
Oui, les mesures de sécurité pour les risques potentiel impactent les performance de certains éléments du kernel, et donc on leur demande de modifier les lignes de code pour contourner ça.

Sauf que ça implique de voir si ça ne risque pas de créer un bug sur plein d'autres processeurs etc
votre avatar
C'est qui le "on" de "on leur demande" ?
votre avatar
Oui car il est employé par la Linux Foundation pour, entre autres, coordonner le développement du noyau. Il pourrait parfaitement refuser les commits des mecs d'Intel à ce titre même si les 2 parties n'y ont aucunement intérêt (côté linux : les mecs d'intel interviennent régulièrement pour des contributions globales à x86 comme les histoires de boot/uefi, la branche PCIe etc. intel est également gros partenaire financier de la LF ; côté intel : linux est hégémonique dans le monde serveur et intel ne peut absolument pas se permettre d'avoir ses dernières générations de CPU/PCH mal supportés sur ces derniers).
votre avatar
Si un CVE sort concernant une faille CPU, elle touche tous les OS.
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...
votre avatar
Après ce qu'a l'air de dire Linus c'est que ça va trop loin pour des cas quasiment impossibles à exploiter, parce qu'il y a maintenant tellement de recherche en sécurité qu'il y a toujours quelqu'un pour tomber sur le moindre truc pas parfait, dire que ça va être un problème et forcer tout le monde à surréagir. Il semble dire qu'il ne veut plus pourrir le code de Linux pour des cas comme ça.

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.
votre avatar
Après, autant au niveau du noyau que des compilateurs, ces "pourrissements" doivent rester optionnels.
Certes mais même si ça reste optionnel, ça rajoute de la complexité a développer, tester et maintenir.
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à,
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,
votre avatar
Spectre/meltdown: à part sur des serveurs vps, c'est quasi impossible à exploiter: chez soi ou au boulot on remarque tout de suite si un cpu est à 100%. Et il faut un temps fou pour extraire des données qui sont dynamique-c'est pas un Snapshot instantané.

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.
votre avatar
J'ai rien compris non plus à sa tirade...
votre avatar
Encore une attaque qui ne cible par réellement le vrai problème.

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).
votre avatar
Il vient à peine de rejoindre le X86 group et déjà il se lâche :D

Linus Torvalds en a « marre » du matériel buggé d’Intel et AMD

Fermer