OpenBSD désactive l'Hyper-Threading en raison de problèmes de sécurité

OpenBSD annonce son intention de désactiver la prise en charge de l'Hyper-Threading des processeurs Intel,
cela en raison de problèmes de sécurité

Pièce jointe 390117

Le projet OpenBSD a annoncé aujourd'hui son intention de désactiver la prise en charge de l'Hyper-Threading des processeurs Intel en raison de problèmes de sécurité concernant la menace théorique d'un plus grand nombre de « bogues de classe Spectre ».

Hyper-Threading (HT) est l'implémentation propriétaire d'Intel de Simultaneous Multithreading (SMT), une technologie qui permet aux processeurs d'exécuter des opérations parallèles sur différents cœurs d'un même processeur multi-core.

Cette fonctionnalité a été ajoutée à tous les processeurs Intel publiés depuis 2002 et a été activée par défaut, Intel citant son amélioration des performances comme principale raison de son inclusion.

Mais aujourd'hui, Mark Kettenis du projet OpenBSD, a dit que l'équipe OpenBSD supprimait le support d'Intel HT parce que, de par sa conception, cette technologie ouvre la porte à d'autres attaques.

Par exemple les attaques à retardement sont une classe d'attaques cryptographiques par lesquelles un observateur tiers peut déduire le contenu des données cryptées en enregistrant et en analysant le temps nécessaire à l'exécution des algorithmes cryptographiques.

Les vulnérabilités récemment révélées des CPU Meltdown et Spectre, ainsi que leurs nombreuses variations[1, 2, 3] sont toutes des attaques chronométrées à leur cœur.

l'Hyper-Threading peut rendre les attaques de synchronisation de cache beaucoup plus faciles et cela peut rendre plusieurs bogues de classe spectre exploitables.

Source : OpenBSD - Undeadly

Et vous ?

:fleche: Que pensez-vous de cette volonté de désactiver l'Hyper-Threading des processeurs Intel ?

Le plus beau dans cette histoire, c'est que chez Intel, l'hyper-threading... sa ce paye!

Sa rend les I7 beaucoup moins attractif par rapport au I5 à même fréquence/cœur physique pour cette OS...

Je peux comprendre leur choix. Surtout que lors de la divulgation de ces failles, Intel ne les a pas averti contrairement à Microsoft et Linux qui ont été avertis en amont. Les devs d'OpenBSD ont du faire des patchs en urgence. Du coup, ça rend la monnaie de la pièce à Intel (même si l'impact va être imperceptible pour le géant) qui le mérite bien ces derniers temps.

Au debut de l'existence de l'exploitation de cette techno par Intel j'avais lu un article dans un magazine spécialisé qui comparait les perfs des CPU mono core avec et sans cette techno.

Il semblait que les perfs était moindre si on utilisait un cpu mono core + core logique au lieu de deux cpu mono core.

Question dev, je crois bien qu'il n'y avait aucune différences.

Citation:

---

Envoyé par MikeRowSoft

Au debut de l'existence de l'exploitation de cette techno par Intel j'avais lu un article dans un magazine spécialisé qui comparait les perfs des CPU mono core avec et sans cette techno.

Il semblait que les perfs était moindre si on utilisait un cpu mono core + core logique au lieu de deux cpu mono core.

Question dev, je crois bien qu'il n'y avait aucune différences.

---

dans le début de cette techno, aucune applie n'étais optimisé ni n'avait été conçue pour la supporter.
donc aucune applie n'a tirait avantage et pire encore cela faisait perdre de la performance (cela se voit assez bien dans les jeux videos de l'époque)
mais aujourd'hui toute les bibliothèques et tous les moteur de jeux supporte l'hyper threading, en 2018 au pire cela n'améliore pas les performances mais cela n'en fait plus perdre contrairement à avant.

tu vaut assimiler cette techno a l'instruction avx 512, sur un pc de particulier cela ne lui améliorera pas les perf de ces logiciels (au début) mais avec les années toutes* les applies l'exploiterons. cela est en faite le cas avec toute les améliorations du x86, le mmx, l'avx, avx2... (en plus pour exploiter l'avx il faut recompiler l'applie)

* je parle d'applie gourmande comme de la traitement video pas les applie style bloc note.

Oui, je suis d'accord avec toi. Et même je dirais que j'ai pu constater qu'un Athlon II X2 avec 2 Mo de mémoire cache L2 (que j'ai eu) était plus apprécier par une application de jeu que le Phenom II X4 ayant 2 Mo de mémoire cache L2 (d'on je dispose).

Pourtant en applications "travail" (applications serveurs) aucune incidence même avec du multimédia (je sais pas pour les réseaux chiffrés et autres types de chiffrements, j'ai pas mesuré les différences lors d'encodages/éditions vidéo ou/et audio sans accélération GPU). ;)

Hyper-Threading ne double pas la capacité de cache, je pense même que c'est de la mémoire partagé et qu'il y a des temps d'attentes quand on peut pas faire autrement. Mais bien évidement, c'est si il n'y a pas suffisamment de mémoire cache.

C'est de l'optimisation qu'il faut au niveau de l'O.S. maintenant en ce qui concerne la mémoire cache et les flux de tâches... Je pense que c'est un peu plus compliqué mais je rejoins l'opinion de OpenBSD si overclocking et Hyper-Threading impliques des sémaphores et des ralentissements en plus de failles de sécurités (surtout si le core physique et le core logique travail sur deux flux commun ou pas en se partageant des adresses de mémoires caches pouvant être altéré). Une application de mesure est très optimisé pour des cas très précis et peut ne pas correspondre à la réalité surtout en mode stress où là il faut prendre en considération le comportement de l'O.S. .

P.S. : oui, overclocker de façon partiel ou non équilibré peut apporter des "ralentissements" (finir une tâche en ayant mis d'autres en pauses tout en sachant qu'il y a déjà beaucoup de tâches en parallèles qui ont les mêmes priorités).