JCC Erratum : un nouveau bug hardware chez Intel

Les bugs hardwares, voilà un terme que nombre d’entreprises redoutent. En effet, si une rustine peut aisément corriger un souci logiciel, les problèmes matériels sont souvent plus coûteux, qu’il s’agisse de performances suite aux correctifs ou de rappels matériels en vue de correctifs. Et, pas de chance, c’est sur Intel que le bâton a, encore une fois frappé, avec un souci matériel embarrassant, nommé JCC Erratum.

Cette fois-ci, le bug touche aux fondamentaux d’un CPU : ses instructions. En effet, ce JCC Erratum signifie Jump Conditionnal Code Erratum : un comportement indéfini (comprenez des crashs potentiels, corruption de données, voire pire) peut avoir lieu sous des conditions spécifiques. Plus précisément, dans un processeur x86, les instructions CISC sont découpées en micro-instructions RISC avant d’être envoyées aux ports les exécutant. Sauf que, dans une optique de performances (toujours !), un buffer a été intégré, de manière à pouvoir retrouver immédiatement les micro-instructions déjà vues sans repasser par la case décodage si ces dernières ont été exécutées suffisamment récemment. Et, comme tous les caches, ce buffer est séparé en lignes de cache, chacune pouvant être vidée indépendamment des autres, et doit être chargée à chaque fois dans son intégralité. Et dans ce Decoded ICache, la taille des lignes est de 32 octets, sauf qu’un bug peut se produire lorsqu’un saut (jump), éventuellement fusionné avec une autre opération de comparaison précédente, est placé à la frontière entre deux lignes. Les détails précis ne sont pas connus, mais, en gros, mieux vaut ne pas être là quand ça arrive !

Un placement spécifique des instructions, mais pas si extraordinaire que ça...

Pour une fois, ce bug n’est pas porteur d’insécurités. Par contre, toutes les applications utilisant des jumps sont touchées... et les branchements conditionnels représentent selon Intel près de 15 % du total des instructions : autant dire que la probabilité de tomber sur un jump potentiellement défectueux au cours de n’importe quel programme est assez élevée. Comprenez donc que tout programme peut potentiellement passer dans une zone corrigé par la rustine, et donc être ralenti. Si Intel communique sur une perte de performance de 4 % en moyenne, des cas pathologiques peuvent se produire dans lesquels l’application sera bien plus lente encore. Notre confrère Phoronix a réalisé un travail de titan pour déterminer dans quelle mesure les temps d’exécutions et nombre d’images par seconde s’en trouvaient dégradés au moyen de deux dossiers — tous deux réalisés sous Linux — disponibles en bas de page. Sans trop spoiler, les résultats dépendent des applications, allant du rien du tout à un bon 10 % en applicatif. Côté gaming, les joueurs sont mieux lotis, car les pertes se situent principalement dans le domaine de l’imperceptible, dépassant difficilement des 2 % d’écart.

Notez que ce correctif correspond à un patch annulant les cas problématiques à l’exécution, mais des moyens sans pertes de performances sont attendus dans les compilateurs (il suffit de rajouter des instructions ou des préfixes qui ne font rien pour modifier la place des instructions dans le programme et éviter ces fameuses frontières). Il faudra par contre repasser par leur moulinette si vous souhaitez utiliser une application rustinée : pas forcément possible pour tous ! Pour ce qui est des CPU impactés, comptez tout le monde depuis Skylake — soit 4 ans de processeurs. De quoi faire encore regretter les Sandy Bridge ? Cela finira par devenir de l’acharnement nostalgique ; par contre il est clair que le concurrent AMD bénéficie indirectement d’une bonne presse, étant complètement non concerné par ce bug. Gageons que la situation s’améliore avec la prochaine révision architecturale (oui, Ice Lake, c’est bien toi que l’on attend !).