URL: https://linuxfr.org/users/kantien/journaux/un-bug-qui-est-le-coupable-le-processeur Title: Un bug ? Qui est le coupable ? Le processeur !!! Authors: kantien Date: 2017年07月04日T15:32:27+02:00 License: CC By-SA Tags: debian Score: 76 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](https://arstechnica.com/information-technology/2017/06/skylake-kaby-lake-chips-have-a-crash-bug-with-hyperthreading-enabled/), et Debian [propose des instructions détaillées pour corriger le problème en mettant à jour le firmware du CPU](https://lists.debian.org/debian-devel/2017/06/msg00308.html). 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](http://gallium.inria.fr/blog/intel-skylake-bug/), 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](https://caml.inria.fr/mantis/view.php?id=7452). 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](http://www.intel.co.uk/content/dam/www/public/us/en/documents/specification-updates/desktop-6th-gen-core-family-spec-update.pdf). 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 : ```C hd = Hd_hp (hp); /*...*/ Hd_hp (hp) = Whitehd_hd (hd); ``` qui après expansion des macros donne : ```C hd = *hp; /*...*/ *hp = hd & ~0x300; ``` Avec Clang, cela donnait : ```asm movq (%rbx), %rax [...] andq $-769, %rax # imm = 0xFFFFFFFFFFFFFCFF movq %rax, (%rbx) ``` tandis que le code optimisé de GCC donnait : ```asm 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](http://passiongenealogie.hautetfort.com/media/00/00/2284501171.jpg)

AltStyle によって変換されたページ (->オリジナル) /