Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Failles Spectre : OpenBSD va désactiver par défaut l’Hyper-Threading des CPU Intel

Failles Spectre : OpenBSD va désactiver par défaut l'Hyper-Threading des CPU Intel

Le 21 juin 2018 à 09h33

Mark Kettenis (développeur pour la distribution) « suspecte fortement » que l'implémentation de SMT donnera lieu à de nombreux autres bugs dans la lignée de Spectre. Il vise notamment l'implémentation d'Intel, mieux connue sous le nom d'Hyper-Threading.

Décision a donc été prise de désactiver l'Hyper-Threading par défaut, mais il est possible de le réactiver via un paramètre hw.smt sysctl. Pour le moment, les processeurs Intel sont les seuls concernés, « mais nous prévoyons d'étendre cette fonctionnalité aux processeurs d'autres fournisseurs et d'autres architectures matérielles », affirme Mark Kettenis.

Ce dernier déclare enfin que le SMT « n'a pas nécessairement un effet positif sur les performances », en fonction de la charge de travail. Il y a néanmoins de fortes chances que les performances baissent si vous avez un CPU avec plus de deux cœurs.

Le 21 juin 2018 à 09h33

Commentaires (29)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar



Ce dernier déclare enfin que le SMT « n’a pas nécessairement un effet positif sur les performances », en fonction de la charge de travail.



Le troll vieux de 18 ans…

votre avatar

Lui il est au courant d’une faille qui n’est pas encore rendue publique, on dirait…

votre avatar

exemple typique de balançage de bébé avec l’eau du bain.



mais bon pour reprendre un petit troll repris de twitter: si personne n’utilise plus openBSD, y’aura plus de failles. <img data-src=" />

votre avatar

Du coup on en est à combien ? 3 failles critiques exploitables à distance depuis 20 ans, c’est ça ?

votre avatar

Je suis assez surpris par l’affirmation du gars, surtout qu’OpenBSD c’est dédié à des serveurs non ? Donc des machines hautement multithreadés…

votre avatar







Obidoub a écrit :



Le troll vieux de 18 ans…





Je ne vois pas en quoi c’est un Troll, c’est un fait qui ressort dans

certains tests : le SMT n’apporte dans certains cas aucun gain.

En revanche, pour un ordinateur personnel étant utilisé pour une grande variété de tâches, c’est une autre histoire.

&nbsp;





hellmut a écrit :



mais bon pour reprendre un petit troll repris de twitter: si personne n’utilise plus openBSD, y’aura plus de failles. <img data-src=" />

&nbsp;





Si c’est une faille matérielle comme Meltdown/Spectre, peu importe l’OS utilisé, la faille sera toujours présente (sauf si l’OS peut corriger l’exploitation de la faille)


votre avatar







Charly32 a écrit :



Je ne vois pas en quoi c’est un Troll, c’est un fait qui ressort dans certains tests : le SMT n’apporte dans certains cas aucun gain.





L’hyper-threading est utile dès qu’il y a congestion des caches/registres. Ça concerne la quasi totalité des algos vu le fréquençage de procos…



J’attends de voir un seul de tes fameux tests. Il n’y a que des test artificiels qui ne profite pas de l’HT/SMT, dès qu’on est dans un cas réel il y a des données qui sont impliqués, et donc on sature le registre. Parfois le gains est de 100%, parfois de 10%, mais on est jamais à 0%, dire le contraire sans avancer de test réel est un troll, oui.


votre avatar

Cf. Ce test : lightroom 6.7 et la totalité des jeux vidéos ne montrent aucun gain significatif avec SMT. x265 est très limité chez Intel.

votre avatar







Charly32 a écrit :



Cf. Ce test : lightroom 6.7 et la totalité des jeux vidéos ne montrent aucun gain significatif avec SMT. x265 est très limité chez Intel.





Allons, allons. C’est pas des tests de HT ça. Un peu de sérieux. C’est mignon un lightroom limité par la RAM et les jeux limités par le GPU, mais faut arrêter de se foutre du monde à un moment.



Le benchmarking ça se fait pas avec un tableau montrant une unique valeur rebasé hein.


votre avatar

Et c’est moi le troll après….

HFR montre dans des cas réels l’influence que peu avoir le réglage activé ou non de l’HT. Moi c’est ce qui m’intéresse en tant qu’utilisateur <img data-src=" />

Les jeux c’est soumis à caution (encore que j’ai toute confiance en HFR pour contrer le GPU limit), mais vu que c’est l’usage le plus courant de mon CPU…

votre avatar







v1nce a écrit :



Du coup on en est à combien ? 3 failles critiques exploitables à distance depuis 20 ans, c’est ça ?





oui, 3 utilisateurs d’OpenBSD <img data-src=" />


votre avatar

Dans mon cas pro (calcul scientifique massivement parallèle avec MPI), on désactive volontairement le SMT en n’utilisant que le nombre de cœurs physique disponible. L’impact de l’HT sur nos temps de calcul s’avère au mieux nul, sinon négatif.

votre avatar







Charly32 a écrit :



Et c’est moi le troll après <img data-src=" />





Bah ouais. Et pour répondre à ton édit, même si ton usage c’est les jeux, si tu ne perd rien à désactiver le HT c’est probablement que ton CPU est surdimensionné par rapport au reste (GPU, fréquence de la RAM, etc.) Ou que le jeu fait bugué l’HT (qui du coup se désactive de lui-même afin de ne pas nuire aux perfs), mais ça devient rare.



Dans 99% des cas, si ton jeu est gourmand en CPU (c’est à dire qu’il profiterait d’une augmentation de la fréquence par exemple via OC de son multiplicateur, et non du bus !) alors le HT l’aidera. Y a pas de secret, tous les composants d’un jeu (rendu 3D, son, IA…) bénéficie de l’HT (test donc sur photoshop avec une modif couteuse en calcul, sur blender avec un rendu 3D, sur Audacity avec un filtre, ou sur n’importe quel soft de solving).



Trouve moi un vrai test d’usage CPU qui ne profite pas de l’HT, je t’en pris…


votre avatar







Eldusole a écrit :



Dans mon cas pro (calcul scientifique massivement parallèle avec MPI), on désactive volontairement le SMT en n’utilisant que le nombre de cœurs physique disponible. L’impact de l’HT sur nos temps de calcul s’avère au mieux nul, sinon négatif.






  Oui mais là on est d'accord que le problème c'est la saturation du MPI du fait de la taille du système, pas le fait que l'HT n'apporte rien sur un serveur, non ? Si vous pouviez augmenter la bande passante et gérer plus d'unité de calcul simultané (ou plutôt diminuer les pertes), activer l'HT vous serait profitable.       







 On est dans un cas limite où chaque nouvelle unité de calcul vous coute cher. Le HPC a ses contraintes qui lui sont propres, on est bien d'accord, c'est d'ailleurs pour ça que ses architectures s'éloignent grandement des PCs classiques (rush vers le PCI 4.0, etc.).

votre avatar







Bejarid a écrit :



J’attends de voir un seul de tes fameux tests.





https://www.phoronix.com/scan.php?page=article&item=intel-ht-2018&am…



Un seul cas, et le HT n’est pas à la ramasse. Dans le reste des cas, +20/+30% grâce au HT, c’est loin d’être négligeable. Jamais de +100%.

Maintenant, sur des serveurs où le CPU n’est JAMAIS au delà de 50% (c’est très fréquent), pourquoi pas. Mais là où on a besoin de perfs, c’est sur la virtualisation, et c’est là que les failles Spectre/Meltdown sont les plus critiques…



Enfin, OpenBSD se veut “secure par défaut”, donc ça tombe sous le sens, il n’y a qu’à réactiver le HT si on s’en sert.


votre avatar







Eldusole a écrit :



Dans mon cas pro (calcul scientifique massivement parallèle avec MPI), on désactive volontairement le SMT en n’utilisant que le nombre de cœurs physique disponible. L’impact de l’HT sur nos temps de calcul s’avère au mieux nul, sinon négatif.





Dans ton cas, si le HT ne sert à rien, désactive le. Mais c’est un cas très particulier, pour lequel tu choisis aussi la machine en fonction.

Masi dans la plupart des cas d’utilisation, le HT est efficace (mais moins que de vrai cœurs)


votre avatar







brice.wernet a écrit :



https://www.phoronix.com/scan.php?page=article&item=intel-ht-2018&num=2



Un seul cas, et le HT n’est pas à la ramasse. Dans le reste des cas, +20/+30% grâce au HT, c’est loin d’être négligeable. Jamais de +100%.



&nbsp;

Yep, on voit d’ailleurs que dans ce cas de mauvais HT, il y a un gros problème de variances (10x plus importante que sans HT, ou quand le HT fonctionne bien). On est clairement dans un cas où le logiciel (l’encodeur de vidéo made in google) bug complètement avec ça, et part en cacahuète.



C’est tout à fait corrigeable si Google le veut, mais comme ils n’utilisent pas trop de x86 pour l’encodage chez eux&nbsp; et optimise leurs softs pour de l’ARM, c’est pas gagné ^^



C’est tout le problème des benchmarks, est-ce que les softs utilisé sont optimisés pour l’architecture testé ?


votre avatar

Pour rappel OpenBSD ce n’est pas que pour les serveurs. Une grande partie des développeurs OpenBSD l’ont sur leur ordinateur portable par exemple.

votre avatar







Eldusole a écrit :



Dans mon cas pro (calcul scientifique massivement parallèle avec MPI), on désactive volontairement le SMT en n’utilisant que le nombre de cœurs physique disponible. L’impact de l’HT sur nos temps de calcul s’avère au mieux nul, sinon négatif.





Ça dépend franchement des codes et des architectures. Je peux te trouver des exemples inverses (toujours dans le domaine du HPC).


votre avatar







Bejarid a écrit :



Trouve moi un vrai test d’usage CPU qui ne profite pas de l’HT, je t’en pris…&nbsp;







Encore une fois, je considère le gain apporté par la techno sur la tâche qui m’intéresse: “si demain mon OS décide de ne plus supporter l’HT, qu’est-ce que j’y perd ?”

Que mon CPU soit chargé qu’à 80% dans mon jeu (même s’il n’est pas limité par le GPU, mais par le moteur du jeu) et que l’IA prenne 0.1µs au lieu de 0.01µs si je devais perdre l’HT, c’est pas ce qui m’intéresse.

Si mon export de RAW avec mon éditeur préféré est limité par le sous-système mémoire, pareil c’est “pas mon problème”. En revanche ce sera probablement celui du développeur dudit logiciel.



Et du coup je ne suis pas d’accord avec ta position qui consiste à traiter de troll ceux qui pointent le fait qu’il existe des cas d’usage où l’HT n’apporte rien / pas grand chose (même si je conçois que dans le cas d’une utilisation générale d’un PC, l’HT soit presque tout le temps bénéfique)



&nbsp;





Bejarid a écrit :



(c’est à dire qu’il profiterait d’une augmentation de la fréquence par exemple via OC de son multiplicateur, et non du bus !) alors le HT l’aidera.





Tu veux dire que le gain provienne seulement de l’augmentation de la fréquence du CPU et non de l’accroissement de bande passante ?


votre avatar







Bejarid a écrit :



Trouve moi un vrai test d’usage CPU qui ne profite pas de l’HT, je t’en pris…





Dans ce document, page 14: +24% une fois le HT désactivé (use case: routeur/firewall).


votre avatar







Charly32 a écrit :



Tu veux dire que le gain provienne seulement de l’augmentation de la fréquence du CPU et non de l’accroissement de bande passante ?






Je veux dire que la fréquence du CPU c'est (fréquence du bus x multiplieur), qui est modifiable sur les série K ou X d'Intel/AMD. Un OC de la fréquence du bus touche aussi la fréquence mémoire, ce qui augmente la bande passante (sauf équilibrage avec son propre multiplieur). L'HT ne touche que ce qui est dans le CPU, si tu touche au CPU ET à la RAM ce n'est plus comparable.




L’hyper-threading est une technologie qui a eu une jeunesse tumultueuse, avec des pertes de perf voir des instabilités. Il est important de souligner que c’est terminé, et qu’elle est aujourdh’ui un vrai gain pour le CPU. Bien sur elle ne sert que dans des cas CPU-bound, mais c’est bien le principe même… Il ne faut pas plus cracher dessus que sur le turbo boost (surfréquençage à la volé de certains coeurs) ou sur les gain de fréquences/architectures des nouvelles versions.



Si la seule solution qu’Intel propose pour corriger les problèmes de sécu c’est de désactiver l’HT plutot que de proposer un vrai patch, on se fait enflé. Et ta position ne fait que les conforter dans cette économie de moyens, en plus d’entretenir un vieux troll (“le HT c’est de la merde”, chose que les fanboys d’AMD ont longtemps propagé car AMD a mit des années à proposer sa version).


votre avatar







gugus69 a écrit :



Dans ce document, page 14: +24% une fois le HT désactivé (use case: routeur/firewall).





La seul chose que le test prouve, c’est qu’il y a un bug sur cette appliance réseau (ce qui est démontré page 15, où l’auteur suppose un problème de thread locking). Mais il se garde bien de tester l’HT avec suffisamment de thread (le proc testé a 8 coeurs, et le teste se limite à… 8 threads !) pour en tester l’efficassité (il manque la ligne “Xeon E5-2650v2 & cxgbe, HT-disabled & 16rxq: inet4 packets-per-second” pour ça).



Ça vaut comme rapport de bug, pas inefficacité de l’HT. Tu es le type même de personne qu’on accuse de troller. Et pas forcément par méchanceté, c’est juste que t’as pas bien creuser le truc et t’as fait une mauvaise interprétation d’un test (ou que t’as repris une conclusion erroné).


votre avatar







Bejarid a écrit :



La seul chose que le test prouve, c’est qu’il y a un bug sur cette appliance réseau (ce qui est démontré page 15, où l’auteur suppose un problème de thread locking). Mais il se garde bien de tester l’HT avec suffisamment de thread (le proc testé a 8 coeurs, et le teste se limite à… 8 threads !) pour en tester l’efficassité (il manque la ligne “Xeon E5-2650v2 & cxgbe, HT-disabled & 16rxq: inet4 packets-per-second” pour ça).





Je ne comprend pas: Cette machine dispose de 8 cœurs (donc 16 threads avec le HT).

Du coup, une fois le HT désactivé, il ne reste bien que 8 threads car quand le HT est désactivé 1 thread = 1 cœur&nbsp; non ?

Alors à quoi cela servirai un test “Xeon E5-2650v2 & cxgbe, HT-disabled & 16rxq” ? car comme HT est désactivé (HT-disabled), il n’y a que 8 threads de disponible en tout, donc pourquoi demander au système d’en utiliser 16 ? Qu’est-ce que cela prouverai ?



&nbsp;

&nbsp;


votre avatar

Les commentaires partent en sucette sur un point de détail.

Ce n’est pas important cette histoite de perfs du SMT / hyperthreading



Ce qui est important c’est que la direction d’openBSD décide de désactiver l’HT par defaut pour des raispns de sécurité



C’est grave ! De quoi toucher tous les i7 vendus depuis 10 ans ! Voire meme Ryzen.



On a des infos sur la faille ?

votre avatar







gugus69 a écrit :



Alors à quoi cela servirai un test “Xeon E5-2650v2 & cxgbe, HT-disabled & 16rxq” ? car comme HT est désactivé (HT-disabled), il n’y a que 8 threads de disponible en tout, donc pourquoi demander au système d’en utiliser 16 ? Qu’est-ce que cela prouverai ?





Pour la même raison qu’il a fait du 8 threads avec HT d’activé (et donc 16 logical core) ? Y a problème avec cette appliance, le but de ces mesures c’est de le comprendre. Il ne s’agit pas d’un test d’efficacité du HT, car là on est dans un cas négatif, pas nul.


votre avatar







neojack a écrit :



On a des infos sur la faille ?





Oui, c’est la faille qu’Intel assume de laisser ouverte par défaut car ils savent pas la fermer en laissant le HT. C’est vieux de quelques semaines.


votre avatar

Ce qu’on peut voir surtout c’est qu’OpenBSD est hyper réactif sur le sujet. Je ne sais pas si les autres OS ont commenté publiquement sur ce sujet.

votre avatar







Charly32 a écrit :



c’est un fait qui ressort dans certains tests : le SMT n’apporte dans certains cas aucun gain.

En revanche, pour un ordinateur personnel étant utilisé pour une grande variété de tâches, c’est une autre histoire.









Bejarid a écrit :



L’hyper-threading est utile dès qu’il y a congestion des caches/registres. Ça concerne la quasi totalité des algos vu le fréquençage de procos…





J’ai aussi constaté que le HT n’a pas toujours d’effet intéressant, sur ma machine avec 2 coeurs et 4 threads (un i3 de portable), parfois je force l’utilisation de 2 threads seulement.


Failles Spectre : OpenBSD va désactiver par défaut l’Hyper-Threading des CPU Intel

Fermer