Journal Un bug ? Qui est le coupable ? Le processeur !!!

Posté par kantien le 04 juillet 2017 à 15:32. Licence CC By‑SA.

Étiquettes :

juil.

2017

Ce journal a été promu en dépêche : Qui est le coupable ? Le processeur ! Retour sur un bogue important des SkyLake & Kaby Lake Intel.

Certains d'entre vous ont peut-être vu passer l'information : les derniers processeurs Intel des familles Skylake et Kaby Lake sont victimes d'un bug lorsque l'hyperthreading est activé. On trouve par exemple un article sur Ars Technica, et Debian propose des instructions détaillées pour corriger le problème en mettant à jour le firmware du CPU.

Néanmoins, dans ce journal, je vais revenir sur les événements qui ont mené à la découverte du problème. Xavier Leroy le décrit en détail dans un article sur le blog de l'équipe Gallium : How I found a bug in Intel Skylake processors, dont je proposerai un résumé pour les lecteurs francophones.

Tout commence en avril 2016 lorsqu'un SIOU (Serious Industrial OCaml User), comme il les appelle, le contacte en privé pour lui signaler un bug dans un de leur logiciel : ce dernier subit des erreurs de ségmentation de manière aléatoire après un certain temps. Il n'arrive pas à reproduire le bug sur sa propre machine et le côté aléatoire du bug lui fait soupçonner un problème matériel chez le client (ram défectueuse, surchauffe…). Il leur propose de tester leur mémoire et de désactiver l'hyperthreading, la mémoire était bonne mais il ne teste pas la désactivation (ce qui aurait résolu le problème).

De son côté le client fait ses tests et aboutit aux résultats suivants : le bug est présent avec la version 4.03 mais pas 4.02.3 du compilateur OCaml, avec GCC mais pas Clang (le runtime OCaml est en C), sur Linux et Windows mais pas OSX (ce qui se comprend, ce dernier utilisant Clang). Les coupables semblent identifiés : OCaml 4.03 et GCC, et le client suppose qu'il y a une erreur dans le code C du runtime.

Début mai 2016, le client offre un accès à leur machine à Xavier Leroy pour qu'il puisse identifier le problème. Il analyse des dumps post-plantage, voit bien des problèmes avec le ramasse-miette mais ne comprend pas ce qui peut causer un tel comportement dans son code. Il fait alors des tests en lançant le programme en parallèle (1, 2 , 4, 8 ou 16 instances) et là tout devient clair : pas de bug quand l'hyperthreading n'est pas utilisé. Ils font des tests en le désactivant dans le BIOS et le problème ne se manifeste plus.

Cela aurait pu en rester là : le client était satisfait de pouvoir utiliser une version du runtime avec Clang, et Xavier Leroy ne sachant pas comment signaler le problème à Intel en reste là. Mais, début 2017, un autre SIOU fait un rapport de bug sur le tracker OCaml. Les symptomes étaient similaires et la discussion sur le ticket fut la suivante :

douze heures après l'ouverture, une des ingénieurs précise que tous les ordinateurs qui ont pu reproduire le bug ont un CPU de la famille Skylake
le lendemain, Xavier Leroy signale son expérience passée et propose de désactiver l'hyperthreading
le jour suivant, un autre ingénieur du SIOU rapporte qu'en désactivant l'hyperthreading le problème disparaît
en parallèle, il constate que si le runtime est compilé avec gcc -O1 et non gcc -O2 alors le bug disparaît. Ce qui permet de comprendre pourquoi cela apparaît avec la version 4.03 qui est celle inaugurant l'option -O2 par défaut pour le runtime
Mark Shinwell contacte des collègues chez Intel et s'occupe de rapporter le problème au support client de Intel.

Enfin 5 mois plus tard, Debian publie une mise à jour du firmware des CPU Intel et Intel publie, en avril, une mise à jour des spécifications de la 6ème génération de ses CPU. On trouve à la page 65 de ce document une mention du problème SKL150 qui était à l'origine de tous ces bugs, présenté en ces termes chez Debian :

SKL150 - Short loops using both the AH/BH/CH/DH registers and
the corresponding wide register *may* result in unpredictable
system behavior.  Requires both logical processors of the same
core (i.e. sibling hyperthreads) to be active to trigger, as
well as a "complex set of micro-architectural conditions"

Pour ceux que cela intéresse et qui comprennent l'assembleur (ce qui n'est pas mon cas), le problème venait de ce bout de code du GC OCaml :

hd = Hd_hp (hp);
/*...*/
Hd_hp (hp) = Whitehd_hd (hd);

qui après expansion des macros donne :

hd = *hp;
/*...*/
*hp = hd & ~0x300;

Avec Clang, cela donnait :

movq    (%rbx), %rax
[...]
andq    $-769, %rax             # imm = 0xFFFFFFFFFFFFFCFF
movq    %rax, (%rbx)

tandis que le code optimisé de GCC donnait :

movq    (%rdi), %rax
[...]
andb    $252, %ah
movq    %rax, (%rdi)

qui pouvait lever le bug du CPU si il se trouvait dans une petite boucle.

Au final, il semblerait que Skylake se soit transformé en Skyfall et que la légendaire crainte gauloise que le ciel leur tombe sur la tête était fondée ! :-D

astérix

# Ce n'est pas la première fois

Posté par Renault (site web personnel) le 04 juillet 2017 à 15:44. Évalué à 10.

Ce n'est pas la première fois (et probablement pas la dernière), qu'un processeur pose des soucis importants. Avec Intel on a même un grand exemple avec le bogue de la division du Pentium.

D'ailleurs les SoC et autres processeurs sont souvent assortis d'une liste d'errata importante, mais les problèmes sont souvent mineurs ou contournables aisément.

Concernant ce cas-ci, nous sommes devant la démonstration intéressante de l'utilité des micro-codes : plutôt que de devoir jeter son processeur à la poubelle (ou de faire des contournements dans la plupart des logiciels pour l'éviter), il suffit d'une mise à jour et c'est reparti. D'où le fait que les fondeurs minimisent au strict nécessaire ce qui est réalisé directement par le matériel, laissant la possibilité de configurer cela avec du logiciel dédié.

Cela n'empêche pas que le code de ces choses là devraient être libres, mais on a un exemple que la solution de fondre le firmware sous forme de transistors directement n'est pas idéale.
- [^] # Re: Ce n'est pas la première fois
  
  Posté par bubar🦥 (site web personnel) le 04 juillet 2017 à 16:45. Évalué à 4. Dernière modification le 04 juillet 2017 à 16:47.
  
  Autre source, sur ce bug de 2015.
  
  Discussion intéressante (du moins, à la date du 25 juin) au sujet de ce bug là
- [^] # Re: Ce n'est pas la première fois
  
  Posté par ʭ ☯ le 04 juillet 2017 à 17:03. Évalué à 1.
  
  Tu n'y es pas, le problème de ces ~~firmware~~microcodes est qu'ils ne sont pas libres. Parce que par exemple le contournement proposé par Intel ici va probablement ralentir certains calculs. Il y a peut-être moyen de coder mieux le correctif. Mais là, on n'y a pas accès….
  
  ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
  - [^] # Re: Ce n'est pas la première fois
    
    Posté par lolop (site web personnel) le 04 juillet 2017 à 17:59. Évalué à 10.
    
    Tu devrais lire jusqu'au bout, il a écrit… «Cela n'empêche pas que le code de ces choses là devraient être libres»
    
    Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
  - [^] # Re: Ce n'est pas la première fois
    
    Posté par claudex le 04 juillet 2017 à 18:01. Évalué à 3.
    
    On ne sait pas si ça va réduire les performances, si ça tombe, le bug est uniquement dans le firmware et pas dans le matériel.
    
    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
  - [^] # Re: Ce n'est pas la première fois
    
    Posté par Guillaume Knispel le 04 juillet 2017 à 20:34. Évalué à 8.
    
    T'as cas prétendre qu'il est pas modifiable et ne pas le patcher, si cet exercice de pensée suffit à te rendre heureux quant à ta liberté.
- [^] # Re: Ce n'est pas la première fois
  
  Posté par ekyo le 04 juillet 2017 à 18:34. Évalué à 5.
  
  Pour que le correctif soit effectif sur la génération kaby lake (dont mon g4560), il faut non seulement mettre à jour le microcode, mais également le bios/uefi. Intel a fourni le correctif il y a plus d'1 mois, et très peu de constructeurs de carte mère proposent à ce jour de versions l'incluant.
  - [^] # Re: Ce n'est pas la première fois
    
    Posté par Anonyme le 05 juillet 2017 à 00:09. Évalué à 2.
    
    Intel a fourni le correctif il y a plus d'1 mois, et très peu de constructeurs de carte mère proposent à ce jour de versions l'incluant.
    
    Si tu as une liste des supports selon les constructeurs et les modèles ça m’intéresse.
    
    Les constructeurs ne sont pas toujours très pressés pour les MÀJ. Quand j'ai cherché une carte-mère d'occasion pour un g4560, j'ai regardé le support des cartes-mères Skylake pour cette génération de processeur (car pas envie d'acheter de la DDR4 et pas de CM compatibles DDR3L sur les nouveaux chipsets). Asus proposait un nouveau BIOS compatible Kabylake dès Janvier, Gigabyte a mis quatre mois de plus pour finaliser le sien.
    
    Ici c'est un bug très rare donc en soi ce n'est pas dramatique de manquer de support, c'est surtout la manière de gérer le correctif et sa propagation qui est inquiétante et qui risque de saper la confiance des clients, même si Intel fait déjà parti des mauvais élèves.
  - [^] # Re: Ce n'est pas la première fois
    
    Posté par oinkoink_daotter le 06 juillet 2017 à 11:32. Évalué à 2.
    
    T'es sûr ?
    
    Dans ces cas là, habituellement, la maj sert surtout à uploader et activer le nouveau microcode à chaque démarrage (car il est "volatile"), pour pallier le support incertain, vu du fondeur, des maj via les OS.
    - [^] # Re: Ce n'est pas la première fois
      
      Posté par Anonyme le 06 juillet 2017 à 13:58. Évalué à 2.
      
      Ce que dit Henrique sur la ML Debian (cf le lien dans l'article) :
      
      The Kaby Lake microcode updates that fix this issue are currently only
      available to system vendors, so you will need a BIOS/UEFI update to get
      it. Contact your system vendor: if you are lucky, such a BIOS/UEFI
      update might already be available, or undergoing beta testing.
      
      La MÀJ du microcode de KabyLake n'est disponible que pour les fabricants de cartes-mères.
      
      Après, je ne pense pas qu'il soit utile d'activer le paquet intel-microcode de Debian puisqu'il ne contiendra que celui pour Skylake et n'aura donc aucune raison de se charger au démarrage.
      J'ose espérer que les MÀJ de BIOS contiendront le correctif pour les deux "générations" que ce soit sur les cartes-mères LGA1151 de première ou de deuxième génération et sur les nouveaux processeurs en LGA2066 qui sont probablement eux aussi touchés par ce bug qui me semble avoir été découvert trop tardivement pour avoir été corrigé avant gravure.
- [^] # Re: Ce n'est pas la première fois
  
  Posté par kantien le 04 juillet 2017 à 22:53. Évalué à 5.
  
  Avec Intel on a même un grand exemple avec le bogue de la division du Pentium.
  
  Oui, c'est le premier exemple qui me soit venu à l'esprit quand j'ai lu l'article de Xavier Leroy. Je ne sais pas si tu l'as lu, mais il a tout de suite envisagé un problème matériel et le cas de l'hyperthreading lui a été inspiré par un autre problème sur l'arithémtique vectorielle et les instructions AVX pour la famille Skylake.
  
  Cela n'empêche pas que le code de ces choses là devraient être libres, mais on a un exemple que la solution de fondre le firmware sous forme de transistors directement n'est pas idéale.
  
  Effectivement, ce qui montre aussi toute l'utilité des projets comme ceux que développent vejmarie sur le matériel Open Source. Cet exemple montre aussi l'intérêt des échanges publiques. Le premier bug fut identifié et résolu en privé, et Xavier Leroy ne savait pas comment contacter Intel en précisant « Intel doesn't have a public issue tracker like the rest of us » dans son article. Le second qui avait la même cause fut discuté publiquement sur le tracker OCaml et quelques mois plus tard il y a un correctif, même s'il reste fermé, grâce à l'intervention de Mark Shinwell.
  
  Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
  - [^] # Re: Ce n'est pas la première fois
    
    Posté par plic le 05 juillet 2017 à 09:28. Évalué à 4.
    
    l'intérêt des échanges publiques
    
    Ah ! Non, pas toi !
    
    La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
- [^] # Re: Ce n'est pas la première fois
  
  Posté par GG (site web personnel) le 05 juillet 2017 à 10:13. Évalué à 1.
  
  la démonstration intéressante de l'utilité des micro-codes […]
  
  Bonjour,
  
  le problème du micro-code, c'est que puisque c'est du code, il y a moins de vérifications. C'est aussi beaucoup plus lent que du micro-cablé.
  Lorsqu'il y a eu le bogue de la division des Intel Pentium, Intel à seulement fourni un patch qui désactivait le co-processeur mathématique dans certaines conditions… donc, les utilisateurs perdaient l'intérêt de cette famille de processeurs.
  
  Le micro-code dans le CPU pousse à bâcler le travail, alors qu'avec du micro-câble, il y a bien plus de vérifications. Et au final on a un truc largement plus rapide. Le micro-cablage, c'est bien.
  
  Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
  - [^] # Re: Ce n'est pas la première fois
    
    Posté par Renault (site web personnel) le 05 juillet 2017 à 10:26. Évalué à 10.
    
    Le micro-code dans le CPU pousse à bâcler le travail, alors qu'avec du micro-câble, il y a bien plus de vérifications. Et au final on a un truc largement plus rapide. Le micro-cablage, c'est bien.
    
    Sauf que tu oublies aussi le coût de l'opération, cela prend de la surface de silicium (donc au détriment peut être d'autres fonction comme de la mémoire cache) et comme cela demande des efforts de développement supplémentaires, le prix de la puce serait plus cher. Et la moindre erreur (car cela arrive aussi avec le matériel malgré les vérifications) a un coût immense.
    
    Comme tout en ingénierie, aucune solution n'est idéale, il faut trouver le compromis entre performances, fiabilité, extensibilité, coût et fonctionnalités. Le 100% silicium n'est clairement pas envisageable. Tout comme le 99,99% logiciel n'est pas terrible non plus.
  - [^] # Re: Ce n'est pas la première fois
    
    Posté par Anthony Jaguenaud le 05 juillet 2017 à 13:16. Évalué à 3.
    
    Lorsqu'il y a eu le bogue de la division des Intel Pentium, Intel à seulement fourni un patch qui désactivait le co-processeur mathématique dans certaines conditions…
    
    Bah, il me semblait que intel avait proposé un échange de processeur. Mais peu de gens l’aurait demandé.
    - [^] # Re: Ce n'est pas la première fois
      
      Posté par GG (site web personnel) le 05 juillet 2017 à 13:56. Évalué à 3.
      
      Je m'en souviens très bien, l'échange était pour les entreprises, le patch pour les particuliers.
      
      et a refusé de remplacer systématiquement les microprocesseurs défectueux. Cependant, si une personne pouvait montrer qu'elle avait été affectée par le dysfonctionnement, alors Intel remplacerait son processeur.
      
      Il fallait donc une démarche lourde pour un particulier.
      
      À la fin, peut être qu'il suffisait de simplement demander le remplacement du processeur, mais dans quelles conditions et comment se serait effectué l'échange?
      
      Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
      - [^] # Re: Ce n'est pas la première fois
        
        Posté par Anthony Jaguenaud le 05 juillet 2017 à 14:44. Évalué à 2.
        
        Je m'en souviens très bien, l'échange était pour les entreprises, le patch pour les particuliers.
        
        Je m’en souviens vaguement… c’était en 1994, ça ne nous rajeunis pas ! J’étais à la FAC et je lisais les magasines d’informatique de l’époque. Hélas, j’ai fini par les jeter dans mes multiples déménagement. J’aurais bien relu des articles de l’époque pour me remémorer tout ça.
  - [^] # Re: Ce n'est pas la première fois
    
    Posté par Guillaume Knispel le 09 juillet 2017 à 02:10. Évalué à 6.
    
    Je sais pas exactement à quoi tu penses en parlant de micro-cablage dans le contexte qui nous intéresse, car dans les archis actuelles (et d'ailleurs en fait aussi beaucoup des anciennes) il n'est pas vraiment envisageable de remplacer le micro-code par d'hypothétiques zones dédiées supplémentaires, et de toutes façon il n'y a aucune raison que la complexité de telles hypothétiques zones dédiées soient notablement inférieures à celle du micro-code (au contraire) et donc que le résultat d'une telle archi soit moins buggué (sauf par des effets indirect du style 30x plus d'efforts de test et validation sur les zones en question par peur d'un bug infixable, mais alors là on risque de dériver vers des considérations économiques…)
    
    Et de toutes façons pour certaines fonctions en guise de zones "dédiées" en question, le seul choix raisonnable sera de balancer une ROM. Donc retour à la case départ.
# Gallium et non pas Gallium

Posté par ʭ ☯ le 04 juillet 2017 à 17:06. Évalué à 7.

Ne pas confondre donc Gallium et Gallium, il n'y a pas de CAML dans MESA3D !

⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# Coquilles

Posté par RyDroid le 04 juillet 2017 à 17:09. Évalué à 5.

Serious Indrustial OCaml User

Industrial, non ?

le runtime est compilé avec ggc -O1 et non ggc -O2

gcc et pas ggc
- [^] # Re: Coquilles
  
  Posté par bubar🦥 (site web personnel) le 04 juillet 2017 à 17:37. Évalué à 2.
  
  Corrigé.
  Merci!
  - [^] # Re: Coquilles
    
    Posté par nlhss (site web personnel) le 04 juillet 2017 à 22:27. Évalué à 4.
    
    Porcesseur ?
    - [^] # Re: Coquilles
      
      Posté par eingousef le 05 juillet 2017 à 10:21. Évalué à 6.
      
      snif snif
      
      tiens ? ça sent le békeune o.O
      
      *splash!*
  - [^] # Re: Coquilles
    
    Posté par kantien le 04 juillet 2017 à 22:34. Évalué à 3.
    Il y en a d'autres :
    - les derniers ~~porcesseurs~~ processeurs Intel
    - ce qui ce se comprend, ce dernier utilisant Clang
    Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
  - [^] # Re: Coquilles
    
    Posté par kantien le 05 juillet 2017 à 00:18. Évalué à 2.
    J'en ai trouvé d'autres :
    - un bug dans un de ~~leur logiciel~~ ses (leurs ?) logiciels
    - le client offre un accès à ~~leur~~ sa (leur ?) machine
    mais là je ne sais si je dois mettre le possessif au singulier ou au pluriel. C'est un peu comme la discussion sur la construction un des : l'adjectif renvoie à un sujet singulier (le client) mais celui-ci désigne une personne morale derrière laquelle se trouve une multitude de personnes physiques. Alors, singulier ou pluriel ? Les deux sont acceptables ?
    
    Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.