Discussion :

[Stéphane le calme]

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

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 6^e et 7^e 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

[Volgaan]

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 ?

[Uther]

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.

[chrtophe]

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.

[LittleWhite]

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 ?

[chrtophe]

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.

[LittleWhite]

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).

[chrtophe]

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.

[Loceka]

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.

[rt15]

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.

[chrtophe]

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/