Intel désactive la fonctionnalité Hardware Lock Elision (HLE) sur tous ses CPU x86 à cause de Zombieload v2
Et recommande en plus de désactiver RTM pour les environnements virtualisés
Le 2019-11-14 23:12:38, par Christian Olivier, Expert éminent sénior
Depuis 2018, plusieurs vulnérabilités affectant les processeurs d’Intel ont été dévoilées. Il a même été démontré que certaines d’entre elles existent depuis près de deux décennies. Ces exploits tirent parti de certains mécanismes d’optimisations implémentés dans les processeurs x86, notamment celui dit de l’exécution spéculative. Les plus connues sont probablement : BranchScope, PortSmash, Meltdown/Spectre, TLBleed et Foreshadow. Ils permettraient à un attaquant d’avoir accès et de détourner différents types de données (mot de passe, historique de navigation d’un navigateur Web, clé cryptographique…) sur un système sans être détecté par les outils de sécurité traditionnels. Les processeurs produits par Intel sont presque toujours les plus sensibles ou les seuls concernés par ces exploits.
Plus tôt cette année, un ensemble de failles de sécurité critiques étroitement liées qui affectent les CPU d’Intel a été publié. Il incluait RIDL (rogue in-flight data load), Microarchitectural Data Sampling (MDS), ZombieLoad et Fallout. La firme de Santa Clara, de son côté, a fait le choix d’utiliser le terme « ;Microarchitect Data Sampling ;» (MDS) pour désigner ce nouvel ensemble de failles critiques. Plus récemment, une nouvelle variante de la vulnérabilité Zombieload a été exposée au grand jour et il a été établi que toutes les microarchitectures de processeurs x86 d’Intel depuis 2013 sont vulnérables à ce nouvel exploit portant le nom de code « ;CVE-2019-11135 ;» ou « ;Zombieload v2 ;» ou faille TAA. Cette nouvelle variante porte à cinq le nombre de vulnérabilités incluses dans la famille MDS telle que définie par Intel. Malheureusement, il n’existe à l’heure actuelle aucune protection matérielle implémentée directement au niveau des processeurs x86 du fondeur américain qui permettrait de se prémunir contre Zombieload v2.
Alors que Cascade Lake, la dernière microarchitecture CPU x86 d’Intel ciblant le marché du HEDT, est censée être immunisée contre Zombieload V1, il a été rapporté que cette microarchitecture CPU est toujours sensible à « ;Zombieload v2 ;». De ce fait, CVE-2019-11135 peut compromettre la sécurité de toutes les plateformes basées sur Cascade Lake qui n’ont pas reçu les patchs de sécurité récemment publiés par la firme de Santa Clara. Ces patchs de sécurité ciblent le logiciel embarqué ou microcode des cartes mères prenant en charge les processeurs Cascade Lake et devraient être distribués par les fabricants de ces cartes sous forme de mises à jour du BIOS. Signalons au passage que les puces x86 d’AMD, notamment celles dérivant de l’architecture Zen, sont intrinsèquement immunisées contre Zombieload v2.
La stratégie d'Intel vis-à-vis de Zombieload v2
Zombieload v2 affecte tous les processeurs d’Intel supportant le jeu d’instruction TSX (Transactional Synchronization Extensions), soit toutes les puces depuis la génération Haswell. La technologie Intel TSX est une extension du jeu d’instructions de l’architecture x86 qui ajoute la prise en charge de la mémoire transactionnelle matérielle afin d’améliorer les performances des logiciels multithreadés. Elle a deux sous-fonctionnalités : Restricted Transactional Memory (RTM) et Hardware Lock Elision (HLE). Selon Intel, le CVSS (Common Vulnerability Scoring System) de cette nouvelle faille est de 6,5.
L’entreprise propose deux procédures d’atténuation du TAA (TSX Asynchronous Abort). L’une se traduit par l’ajout du Model Specific Register (MSR) IA32_TSX_CTRL qui permet de désactiver RTM seul ou RTM et HLE en même temps. L’autre est basée sur les anciennes solutions de mitigations de MDS et permet de supprimer les données périmées présentes au niveau du CPU par le biais d’une instruction VERW qui efface tous les tampons de la puce. Il semble, par ailleurs, que l’application du nouveau patch de sécurité d’Intel « ;désactive inconditionnellement ;» la fonctionnalité HLE des CPU cibles qui reste malgré tout listée comme une fonctionnalité présente. Intel recommande non seulement la désactivation de HLE, mais aussi celle de RTM pour les environnements virtualisés.
Comme l'a récemment souligné un développeur du noyau Linux, il faut rappeler qu'à cause des failles matérielles qui affectent les processeurs Intel et des différentes solutions de mitigation publiées par la firme de Santa Clara, il est recommandé aux utilisateurs, professionnels et entreprises soucieux de la sécurité de leurs données de désactiver la technologie Hyperthreading sur leurs systèmes basés sur des processeurs Intel. Par ailleurs, ils doivent tous s'attendre à une réduction des performances - de l'ordre de 20 % environ (jusqu'à 40 % dans certains cas) - sur les systèmes basés sur les processeurs Intel sensibles à ces différents exploits. La découverte de nouvelles vulnérabilités matérielles comme Zombieload v2 et la publication de nouvelles mesures d'atténuation ne fera probablement qu'aggraver ces désagréments.
Source : Intel, Linux Kernel
Et vous ?
Qu’en pensez-vous ?
Voir aussi
MDS : de nouveaux exploits liés à l'exécution spéculative qui affectent les CPU Intel jusqu'à Kaby Lake et exposent les données des mémoires tampon
Spectre/Meltdown : de nouvelles failles dans les processeurs, elles permettent de lire les registres internes, la mémoire kernel et celle de l'hôte
PortSmash : une nouvelle faille critique qui affecte les CPU Intel exploitant l'Hyperthreading ou le SMT. Des CPU AMD pourraient aussi être touchés
Plus tôt cette année, un ensemble de failles de sécurité critiques étroitement liées qui affectent les CPU d’Intel a été publié. Il incluait RIDL (rogue in-flight data load), Microarchitectural Data Sampling (MDS), ZombieLoad et Fallout. La firme de Santa Clara, de son côté, a fait le choix d’utiliser le terme « ;Microarchitect Data Sampling ;» (MDS) pour désigner ce nouvel ensemble de failles critiques. Plus récemment, une nouvelle variante de la vulnérabilité Zombieload a été exposée au grand jour et il a été établi que toutes les microarchitectures de processeurs x86 d’Intel depuis 2013 sont vulnérables à ce nouvel exploit portant le nom de code « ;CVE-2019-11135 ;» ou « ;Zombieload v2 ;» ou faille TAA. Cette nouvelle variante porte à cinq le nombre de vulnérabilités incluses dans la famille MDS telle que définie par Intel. Malheureusement, il n’existe à l’heure actuelle aucune protection matérielle implémentée directement au niveau des processeurs x86 du fondeur américain qui permettrait de se prémunir contre Zombieload v2.
Alors que Cascade Lake, la dernière microarchitecture CPU x86 d’Intel ciblant le marché du HEDT, est censée être immunisée contre Zombieload V1, il a été rapporté que cette microarchitecture CPU est toujours sensible à « ;Zombieload v2 ;». De ce fait, CVE-2019-11135 peut compromettre la sécurité de toutes les plateformes basées sur Cascade Lake qui n’ont pas reçu les patchs de sécurité récemment publiés par la firme de Santa Clara. Ces patchs de sécurité ciblent le logiciel embarqué ou microcode des cartes mères prenant en charge les processeurs Cascade Lake et devraient être distribués par les fabricants de ces cartes sous forme de mises à jour du BIOS. Signalons au passage que les puces x86 d’AMD, notamment celles dérivant de l’architecture Zen, sont intrinsèquement immunisées contre Zombieload v2.
La stratégie d'Intel vis-à-vis de Zombieload v2
Zombieload v2 affecte tous les processeurs d’Intel supportant le jeu d’instruction TSX (Transactional Synchronization Extensions), soit toutes les puces depuis la génération Haswell. La technologie Intel TSX est une extension du jeu d’instructions de l’architecture x86 qui ajoute la prise en charge de la mémoire transactionnelle matérielle afin d’améliorer les performances des logiciels multithreadés. Elle a deux sous-fonctionnalités : Restricted Transactional Memory (RTM) et Hardware Lock Elision (HLE). Selon Intel, le CVSS (Common Vulnerability Scoring System) de cette nouvelle faille est de 6,5.
L’entreprise propose deux procédures d’atténuation du TAA (TSX Asynchronous Abort). L’une se traduit par l’ajout du Model Specific Register (MSR) IA32_TSX_CTRL qui permet de désactiver RTM seul ou RTM et HLE en même temps. L’autre est basée sur les anciennes solutions de mitigations de MDS et permet de supprimer les données périmées présentes au niveau du CPU par le biais d’une instruction VERW qui efface tous les tampons de la puce. Il semble, par ailleurs, que l’application du nouveau patch de sécurité d’Intel « ;désactive inconditionnellement ;» la fonctionnalité HLE des CPU cibles qui reste malgré tout listée comme une fonctionnalité présente. Intel recommande non seulement la désactivation de HLE, mais aussi celle de RTM pour les environnements virtualisés.
Comme l'a récemment souligné un développeur du noyau Linux, il faut rappeler qu'à cause des failles matérielles qui affectent les processeurs Intel et des différentes solutions de mitigation publiées par la firme de Santa Clara, il est recommandé aux utilisateurs, professionnels et entreprises soucieux de la sécurité de leurs données de désactiver la technologie Hyperthreading sur leurs systèmes basés sur des processeurs Intel. Par ailleurs, ils doivent tous s'attendre à une réduction des performances - de l'ordre de 20 % environ (jusqu'à 40 % dans certains cas) - sur les systèmes basés sur les processeurs Intel sensibles à ces différents exploits. La découverte de nouvelles vulnérabilités matérielles comme Zombieload v2 et la publication de nouvelles mesures d'atténuation ne fera probablement qu'aggraver ces désagréments.
Source : Intel, Linux Kernel
Et vous ?
Voir aussi
-
SteinvikelMembre expertCertains logiciels tirent parti de la fréquence max du CPU, d'autres, du nombre max de coeurs physiques (SMT/HT compris) ...et certains semble plutôt "équilibrés" entre ces deux cas.
Est-il vraiment pertinent de dire que tel ou tel fabricant fabrique de meilleurs produits que son concurrent, alors qu'outre le type de logiciel que l'on souhaite faire tourner dessus, c'est l'implémentation exacte du logiciel qui va, en finalité, dicter si tel ou tel produit est plus approprié pour afficher les meilleurs performances.
La preuve en est faite régulièrement par les bench faussés à coups d'optimisations pour des "contextes" volontairement favorables. Que se soit par du matos équipé de BIOS "presse", ou des démos qui font tourner des scènes s'appuyant fortement sur la solution à mettre en avant pour dire que "ma solution générique est meilleur !".
Réveillez-vous, faite la paix, et partagez vos connaissances... expliquez-vous !le 16/11/2019 à 2:31 -
Fleur en plastiqueMembre extrêmement actifRaz le bol de toutes ces failles sur les CPUs Intel
Une chose est sûre : mon prochain CPU sera un AMD.le 15/11/2019 à 11:53 -
luciole75wFutur Membre du ClubMerci pour l'info.
Il y a une erreur dans le chemin de la clé (un "\Control" en trop). La commande donnée par microsoft pour déactiver TSX est :
Code : reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel" /v DisableTsx /t REG_DWORD /d 1 /f
le 15/11/2019 à 21:16 -
chrtopheResponsable SystèmesPetite question d’un néophyte : Pourquoi c’est mieux, la compilation sur Intel ?
Il peut y avoir des différences de perfs, mais il faut avant tout comparer ce qui est comparable, comparer à fréquence équivalente, taille de cache équivalent nombre de cœurs équivalents, type et quantité de RAM équivalente. Et vu le nombre de produits, c’est pas évident de faire une comparaison juste et objective, surtout qu'il faut aussi prendre en compte les perfs des chipsets.
Après si tu utilises le compilateur Intel avec un CPU Intel, tu auras probablement de meilleures perfs qu'avec un AMD supporté par ce même compilateur.
Tout comme tu pourras avoir une différence d'efficacité entre une compilation sous Windows et une sous Linux, mais il sera objectivement difficile d'impliquer ses différences au compilateur plutôt qu'à l'OS.le 30/11/2019 à 11:26 -
jvalloisMembre éprouvéle 15/11/2019 à 13:21
-
SarényaMembre habituéà par si tu parle du compilateur intel, c'est complètement faux : http://www.comptoir-hardware.com/articles/cpu-mobo-ram/39774-test-ryzen-3000-a-x570-round-2.html?start=9le 15/11/2019 à 22:04
-
AiekickMembre extrêmement actifje ne vais pas jusque la, mais j'ai testé des proc amd et intel équivalent en cache et nombre de coeur. et que ce soit avec le compiler visual studio, mingw32, ou clang, dans tous les cas le compil plus vite avec intel. apres bon c'est mon avis, vous faites ce que vous voulez.le 02/12/2019 à 15:43
-
AiekickMembre extrêmement actifdu coup avec cette perte de performance, il seront au niveau des puces AMD.. perso je reste sur intel, pour la compilation ya pas mieuxle 15/11/2019 à 13:12
-
AiekickMembre extrêmement actifla rapiditéle 15/11/2019 à 17:56