Cela fait longtemps que les failles et autres vulnérabilités ne sont plus au devant de la scène. Mais c’était sans compter sur une petite nouvelle de l’été, SQUIP, qui affecte plus particulièrement les AMD Ryzen. Pour contrer une vulnérabilité, la solution est globalement toujours la même : une rustine soft qui solutionne le problème mais qui consomme tout de même des ressources, mêmes modestes. Le problème avec SQUIP c’est qu’apparemment la parade consiste à désactiver le SMT ( c’est à dire le multi-threading ). Voilà donc une faille qui risque potentiellement d’handicaper les propriétaires de CPU AMD.
La conception spécifique des CPU AMD Zen fait qu’ils seraient les seuls touchés. D’après un chercheur en informatique à l’Université de technologie de Graz ( Autriche ), celte faille toucherait les processeurs AMD et non Intel en raison des files d’attente de planification à plusieurs niveaux distinctes, tandis qu’Intel utilise un seul planificateur. D’après AMD, pratiquement tous les processeurs AMD Zen 1 , Zen 2 et Zen 3 de l’entreprise sont concernés. Les Athlon 3000 seraient également touchés.
Ce qui est perturbant dans cette histoire c’est qu’AMD n’a pas fourni, pour le moment de véritable solution pour contrer la vulnérabilité SQUIP. Les rouges considèrent cette vulnérabilité comme d’importance moyenne. A cet instant, la seule solution recommandée pour contrer SQUID est donc de désactiver le SMT de notre CPU AMD. Evidemment, une telle opération entraine une dégradation majeure des performances. La seule question qui se pose donc réellement concerne l’ampleur de la diffusion de SQUID. AMD renvoie la balle dans le camp des développeurs qui doivent prendre leurs dispositions s’ils sont touchés ( en désactivant le SMT ? ). Mais si les problèmes prennent de l’ampleur, seront nous d’accord pour castrer volontairement nos processeurs de 50% de leurs performances ?
La nouvelle sort à point nommé… Quelques semaines avant la sortie des Ryzen 7000… Tout en mettant en avant Intel qui perd des parts de marché conséquente… Quant à la recherche entre autres experts… ne sont pas exempt de conflit d’intérêts… (d’exp perso validé)
Ce qui serait cool ce serait plus d’avoir un article qui explique comment désactiver ces amputations sur nos chers OS afin de bénéficier pleinement des investissements matériels que nous faisons et sans avoir l’impression de se faire plumer par une limitation logicielle qui arrange tous les industriels. C’est d’autant plus frustrant quand on lit le descriptif des failles en question (style la faille d’intel qui permet des fuites mémoires d’une vm à l’autre … non mais franchement qu’est ce qu’on en a à battre). Je décernerai bien la médaille de l’emmerdeur suprême à ces chercheurs qui trouvent des failles la… Lire la suite »
Intel l’a fait et c’est passé comme une lettre a la poste… Personne n’a réagi. Le monde actuel est étonnant.
Les failles Spectre et Meltdown et la réduction de performance associée ont fait beaucoup de bruit au sein de la communauté. De plus, on parle ici de mitiger la faille en désactivant le multithreading, je ne sais pas si tu comprends ce que cela représente en terme d’impact performance. Il n’est pas si simple que de dire que ces failles et leurs remediations sont identiques, le monde actuel est plus complexe qu’il n’y parait.
Ce qui serait bien, c’est contextualiser le danger… Si je comprends bien, cela devient problématique dans le cas d’un hôte compromis, dans la mesure où il serait possible de récupérer les clés de chiffrements et de passer de thread en thread, récupérant ainsi des infos à la volée sur une charge de travail. Il est oublié également dans l’article, que les CPU Apple M1 ayant, eux aussi, plusieurs scheduler, pourraient être potentiellement impactés. Quand on voit le niveau de sophistication de ces attaques, je doute que cela concerne beaucoup de particulier… donc comme d’habitude, c’est la balance bénéfice-risque qui fera… Lire la suite »