Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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 , par Christian Olivier

27PARTAGES

9  0 
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

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Steinvikel
Membre chevronné https://www.developpez.com
Le 16/11/2019 à 2:31
Certains 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 !
3  0 
Avatar de Fleur en plastique
Membre habitué https://www.developpez.com
Le 15/11/2019 à 11:53
Raz le bol de toutes ces failles sur les CPUs Intel

Une chose est sûre : mon prochain CPU sera un AMD.
2  0 
Avatar de luciole75w
Candidat au Club https://www.developpez.com
Le 15/11/2019 à 21:16
Citation Envoyé par Christian Olivier Voir le message
La firme de Redmond a publié sur son site un avis sur la façon dont les administrateurs système peuvent désactiver (1) ou réactiver (2) la fonctionnalité TSX en utilisant des clés de registre comme suit :
(1)
Code : Sélectionner tout
1
2
reg add
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Control\Session Manager\Kernel" /v DisableTsx /t REG_DWORD /d 1 /f
(2)
Code : Sélectionner tout
1
2
reg add
 « HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Control\Session Manager\Kernel » /v DisableTsx /t REG_DWORD /d 0 /f
...
Source : Microsoft, Linux, Intel
Merci 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 : Sélectionner tout
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel" /v DisableTsx /t REG_DWORD /d 1 /f
1  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 30/11/2019 à 11:26
Petite question d’un néophyte : Pourquoi c’est mieux, la compilation sur Intel ?
Ce n'est ni mieux ni moins bien.

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.
1  0 
Avatar de jvallois
Membre habitué https://www.developpez.com
Le 15/11/2019 à 13:21
Citation Envoyé par Aiekick Voir le message
perso je reste sur intel, pour la compilation ya pas mieux
Petite question d’un néophyte : Pourquoi c’est mieux, la compilation sur Intel ?
0  0 
Avatar de Sarénya
Membre régulier https://www.developpez.com
Le 15/11/2019 à 22:04
Citation Envoyé par Aiekick Voir le message
du coup avec cette perte de performance, il seront au niveau des puces AMD.. perso je reste sur intel, pour la compilation ya pas mieux
à par si tu parle du compilateur intel, c'est complètement faux : http://www.comptoir-hardware.com/art...2.html?start=9
0  0 
Avatar de Aiekick
Membre extrêmement actif https://www.developpez.com
Le 02/12/2019 à 15:43
je 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.
0  0 
Avatar de Aiekick
Membre extrêmement actif https://www.developpez.com
Le 15/11/2019 à 13:12
du coup avec cette perte de performance, il seront au niveau des puces AMD.. perso je reste sur intel, pour la compilation ya pas mieux
0  3 
Avatar de Aiekick
Membre extrêmement actif https://www.developpez.com
Le 15/11/2019 à 17:56
la rapidité
0  3