OpenBSD a désactivé la technologie Hyper-Threading d'Intel, citant des soucis de sécurité - apparemment, des préoccupations de type Spectre .
Comme indiqué dans cette publication :
OpenBSD a donc décidé de désactiver l'hyper-threading du processeur Intel, avec "un nouveau hw.smt sysctl
", afin d'éviter que les données ne fuient des applications vers d'autres logiciels via des failles de processeur semblables à celles du Spectre.
Insane dans le domaine
Il n'y a pas grand chose de plus expliquant la décision prise dans la publication de Kettenis, si ce n'est l'observation suivante:
Il y a, cependant, un autre indice sur la raison pour laquelle dans ce poste de Philip OpenBSD chap Guenther, qui a commis un changement à « effacer les GPR en entrant dans le noyau de l' espace utilisateur afin que les valeurs contrôlées par l' utilisateur ne peuvent pas prendre part à l' exécution spéculative le noyau descend les chemins qui finissent 'non pris' mais qui peuvent provoquer des effets visibles par l'utilisateur (cache, etc). "
Ce commit était accompagné d'une demande de désactivation de l'hyper-threading Intel.
Nous avons également repéré ce message de Seclists mentionnant la décision d'OpenBSD et faisant allusion à une révélation connexe le 27 juin. Et cette discussion à Black Hat en août promet de révéler comment les malfaiteurs peuvent extraire les clés de chiffrement de la mémoire de l'application via l'hyper-threading et les données TLB fuites.
Plus précisément, cette présentation, par Ben Gras, couvrira une technique appelée TLBleed qui exploite l'hyper-threading pour balayer des données sensibles:
Notre exploit TLBleed laisse fuir une clé EdDSA de 256 bits de libgcrypt (utilisée par ex. GPG) avec un taux de réussite de 98% après une seule observation d'une opération de signature sur un hyper-thread co-résident et 17 secondes de temps d'analyse.
Nous avons demandé à Kettenis d'offrir plus d'informations, et à Intel de commenter, mais aucun d'entre eux n'avait été en contact au moment de la rédaction.
Performance
Le post de Kettenis suggère que l'hyper-threading invalidant ne sera pas un gros problème car "SMT n'a pas nécessairement un effet positif sur la performance; cela dépend fortement de la charge de travail. Selon toute probabilité, cela ralentira la plupart des charges de travail si vous avez un processeur avec plus de deux cœurs.
Il ne se trompe pas: à moins que le code ne soit écrit avec l'hyper-threading à l'esprit, l'avantage de la performance n'est pas énorme, et pas beaucoup de code tire parti de la fonctionnalité. Hyper-treading fonctionne en permettant à un noyau de CPU d'exécuter plusieurs threads à la fois, par opposition à un thread par core.
Intel, cependant, commercialise l'hyper-threading comme une vertu distincte: ses fiches de spécifications CPU mentionnent toujours le nombre de threads et de noyaux.
Les indices de nouvelles inquiétudes en matière de sécurité ressemblant à des Spectres seront donc très mal accueillis par Chipzilla. La communauté OpenBSD a été harcelée par les mesures prises pour dévoiler les failles de conception de Meltdown et de Specter - gelanteffectivement une partie du monde de BSD des collaborations privées sur des atténuations - et a appelé pour que de telles révélations soient traitées différemment à l'avenir. ®
Source : theregister.co.uk
Suivez ce blog : Newsletter, Mail
Suivez-moi sur : Framasphere, Twitter
Commenter cet article