Tout commence en avril 2016 lorsqu’un SIOU (Serious Industrial OCaml User), comme il les appelle, le contacte en privé pour lui signaler un bogue dans un de leur logiciel : ce dernier subit des erreurs de segmentation de manière aléatoire après un certain temps. Il n’arrive pas à reproduire le bogue sur sa propre machine et le côté aléatoire du bogue lui fait soupçonner un problème matériel chez le client (mémoire vive défectueuse, surchauffe…). Il leur propose de tester leur mémoire et de désactiver l’hyper‐threading. 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 bogue est présent avec la version 4.03 mais pas la 4.02.3 du compilateur OCaml, avec GCC mais pas Clang (l’environnement d’exécution d’OCaml est en C), sur GNU/Linux et Windows mais pas macOS (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 de l’environnement d’exécution d’OCaml.
Début mai 2016, le client offre un accès à sa machine à Xavier Leroy pour qu’il puisse identifier le problème. Il analyse des vidages mémoire (dumps) post‐plantage, voit bien des problèmes avec le ramasse‐miettes, 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 bogue quand l’hyper‐threading 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 de l’environnement d’exécution 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 bogue sur le système de suivi d’OCaml. Les symptômes é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 bogue ont un processeur de la famille Skylake ;
- le lendemain, Xavier Leroy signale son expérience passée et propose de désactiver l’hyper‐threading ;
- le jour suivant, un autre ingénieur du SIOU rapporte qu’en désactivant l’hyper‐threading le problème disparaît ;
- en parallèle, il constate que si l’environnement d’exécution est compilé avec
gcc -O1 et non gcc -O2 alors le bogue 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 l’environnement d’exécution ;
- Mark Shinwell contacte des collègues chez Intel et s’occupe de rapporter le problème au support client d’Intel.
Enfin, cinq mois plus tard, Debian publie une mise à jour du microcode des processeurs Intel et Intel publie, en avril, une mise à jour des spécifications de la 6e génération de ses processeurs. On trouve à la page 65 de ce document une mention du problème SKL150 qui était à l’origine de tous ces bogues, 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 ramasse‐miettes d’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 bogue du processeur s’il se trouvait dans une petite boucle ?
Ce bogue sur ces processeurs impacte tous les systèmes d’exploitation. Le correctif du microcode pour la génération Skylake existe donc depuis avril, car Intel distribue ses mises à jour à toutes et tous, permettant aux mainteneurs des distributions de réaliser l’empaquetage afin de les rendre disponibles.
Cependant, il n’en va pas de même pour la génération Kaby Lake, pour laquelle Intel ne distribue ses correctifs de microcodes qu’aux seuls constructeurs ou assembleurs. Il résulte de cette situation une grande disparité des disponibilités pour cette mise à jour : certains constructeurs l’ont déjà proposée, d’autres ne le font pas.
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
