IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

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 !

Un bogue critique dans l'hyper-threading des puces Intel Skylake et Kaby Lake a été découvert
Il peut provoquer des pertes de données

Le , par Stéphane le calme

5PARTAGES

14  1 
Dans la liste de diffusion de Debian, le développeur Debian Henrique de Moraes Holschuh a mis en garde les utilisateurs d’un processeur Intel Core de sixième ou septième génération sur l’existence d’un bogue au niveau de l’hyper threading.

Pour rappel, l'hyper threading d'Intel est une technologie qui permet d'exécuter deux routines (Thread) simultanément (SMT) d'un même programme ou de deux différents. L'hyperthreading crée deux microprocesseurs logiques dans le même microprocesseur: chacun partageant les fonctionnalités du processeur physique : bus internes, registres, unités de calculs, mémoires cache... Son utilisation nécessite un processeur, chipset, système d'exploitation et logiciel compatibles.

« Cette alerte est pertinente pour les utilisateurs de systèmes disposant de processeurs Intel nommés "Skylake" et "Kaby Lake". Ce sont des processeurs Intel Core de 6e et 7e génération (desktop, système embarqué, mobile et HEDT), leurs processeurs de serveurs associés (tels que Xeon v5 et Xeon v6), ainsi que certains modèles de processeur Intel Pentium », a-t-il indiqué.

« Dans certaines situations, les processeurs non colmatés de Skylake et de Kaby Lake pourraient se comporter de façon dangereuse lorsque l'hyper-threading est activé. Désactivez l'hyper-threading immédiatement dans BIOS/UEFI pour contourner le problème. »

Le développeur affirme que ce bogue peut, lorsqu'il est déclenché, provoquer un comportement système imprévisible qui pourrait causer des erreurs parasites telles que des comportements inattendus des applications et du système, une corruption des données et une perte de données.

Concernant les distributions GNU / Linux Debian 9 « Stretch » et Debian 8 « Jessie » une mise à jour du « package Intel-microcode » est déjà disponible afin de corriger le bogue. Les utilisateurs sont invités à mettre à niveau leur distribution dès sa disponibilité dans les dépôts « non libre » ou « jessie-backports ».

Dans son avertissement, le développeur souligne qu’un correctif est disponible pour Kaby Lake, mais réservé aux constructeurs. Les utilisateurs doivent donc contacter leurs fournisseurs pour vérifier si la mise à jour est disponible de leur côté. Il précise également qu’il est possible d’installer soi-même le microcode corrigé d’Intel (version 3.20170511.1) pour les modèles 78 ou 94 des processeurs, mais cela requiert un certain niveau de connaissance technique sous Linux.

« Veuillez noter que le bogue peut affecter tout système d'exploitation (il n'est pas restreint à Debian, et ne se limite pas aux systèmes Linux). Il peut être soit évité (en désactivant l'hyper-threading), soit corrigé (en mettant à jour le microcode du processeur) », a précisé le développeur. En clair, le bogue des processeurs d’Intel touche l’ensemble des OS exploitant les puces concernées et pas seulement la distribution Debian et le noyau Linux.

« En raison de la détection difficile des logiciels potentiellement affectés et du caractère imprévisible du bogue, tous les utilisateurs Intel concernés sont fortement invités à prendre des mesures comme celles qui sont recommandées par cette alerte ».

La communauté OCaml a d'abord commencé à enquêter sur les processeurs avec ces dysfonctionnements en janvier et a trouvé des rapports remontant au moins au premier semestre de 2016. L'équipe OCaml a pu identifier le problème à l'implémentation HyperThreading de Skylake et a informé Intel. Alors qu'Intel n'a pas répondu directement, l'entreprise a publié des correctifs sous forme de microcode depuis lors, mais ils devront être intégrés dans la carte mère UEFI pour fonctionner efficacement.

Source : liste de diffusion Debian, OCaml

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

Avatar de Volgaan
Membre confirmé https://www.developpez.com
Le 27/06/2017 à 11:29
On n'a pas plus d'informations sur le bug en lui-même ? Comment se déclenche-t-il et qu'est-ce qu'il cause exactement au sein du processeur ?
2  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 27/06/2017 à 20:46
Aucun compilateur moderne ne va utiliser ces registres 8 bits, à moins de lui demander explicitement avec du code inline. Je pense que c'est même contre productif car les données et instructions doivent être alignés sur 8 octets (fait par le compilateur) pour pouvoir bénéficier correctement des caches et prédictions de branchements.

Je pense que les CPU récents émulent la possibilité d'accès aux registres AH, AL, AX etc.. pour rétrocompatibilité, et que c'est cette émulation buguée la source du problème. Mais ce n'est qu'une supposition.
1  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 27/06/2017 à 15:08
D'après le rapport de Intel cité par Debian :
Problem: Under complex micro-architectural conditions, short loops of less than 64 instructions that use AH, BH, CH or DH registers as well as their corresponding wider register (e.g. RAX, EAX or AX for AH) may cause unpredictable system behavior. This can only happen when both logical processors on the same physical processor are active.
Implication: Due to this erratum, the system may experience unpredictable system behavior.
A priori, la cause est un bug dans le microcode, vu qu'il peut être corrigé par un patch.
0  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 27/06/2017 à 19:41
Apparemment, si j'ai bien compris, c'est lié à l'utilisation des registres AH, BH, CH, DH, que l'on utilise plus sur des applis modernes.
0  0 
Avatar de LittleWhite
Responsable 2D/3D/Jeux https://www.developpez.com
Le 27/06/2017 à 19:52
Citation Envoyé par chrtophe Voir le message
Apparemment, si j'ai bien compris, c'est lié à l'utilisation des registres AH, BH, CH, DH, que l'on utilise plus sur des applis modernes.
Ah ? Quel registre utilisez-vous du coup ?
0  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 27/06/2017 à 20:10
les registres utilisés sont RAX en 64 bits, EAX en 32 bits . AX représente les 16 bits de poids faible de EAX, AH représente les 8 bits de poids fort de AX. Ceci applicable aux registres RAX, RBX, RCX, RDX. C'est l'usage des registres 8 bits et 32/64 ensemble qui semble planter le CPU dans certaines conditions (boucle de moins de 64 instructions avec l'usage de 2 CPU logiques sur le même CPU physique ), du moins d'après ce que j'ai compris de l'extrait cité par Uther.
0  0 
Avatar de LittleWhite
Responsable 2D/3D/Jeux https://www.developpez.com
Le 27/06/2017 à 20:29
Dans mon esprit, AX, EAX, RAX, AH, AL sont tous un même registre. Par contre, c'est le nombre de bits pris en compte dans l'opération qui change.
Du coup, dire que vous ne les utilisez plus, c'est un raccourci. Vous les utilisez implicitement (et même si dans les applications modernes, on travaille sur le plus de données à la fois (donc E*X), le noyau peut être plus précis.
Aussi, on peut peut être imaginer que le compilateur fait de l'optimisation de registres en compactant plusieurs données dans un grand registre (car les registres sont avantageux).
0  0 
Avatar de Loceka
Expert confirmé https://www.developpez.com
Le 29/06/2017 à 14:17
Y'a moyen d'avoir un peu plus d'info sur le patch ?

Où le trouver ? Comment l'appliquer (flash du BIOS ? MàJ depuis l'OS ?) ? etc.
0  0 
Avatar de rt15
Membre éclairé https://www.developpez.com
Le 22/01/2018 à 13:23
Citation Envoyé par chrtophe Voir le message
Aucun compilateur moderne ne va utiliser ces registres 8 bits, à moins de lui demander explicitement avec du code inline. Je pense que c'est même contre productif car les données et instructions doivent être alignés sur 8 octets (fait par le compilateur) pour pouvoir bénéficier correctement des caches et prédictions de branchements.

Je pense que les CPU récents émulent la possibilité d'accès aux registres AH, AL, AX etc.. pour rétrocompatibilité, et que c'est cette émulation buguée la source du problème. Mais ce n'est qu'une supposition.
Gros déterrage de topic pour grosse correction.
Les registres 8 bits sont utilisés dans les applications modernes.
Ci-dessous on voit bien que le compilo met le caractère dans le registre AL pour l'incrémenter.

0  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 22/01/2018 à 18:07
Comme je l'avais dit, il ne s'agissait que d'une supposition.

Je me demande quand-même si ce n'est pas plus couteux en cycles d'utiliser les registres al à dl.

Et pour en revenir au sujet, c'est l'usage de ces anciens registres qui est problématique par rapport au bug évoqué, enfin dans certains cas précis.

Peut-être un lien avec ceci (défaut de conception) :
https://www.developpez.com/actu/1812...arche-serveur/
0  0