Le 29 août 2026, Christian Ludloff, auteur de la référence x86 sandpile.org, a publié sur la liste de diffusion du noyau Linux une série de préfixes WBINVD jusque là non documentés, en demandant que ces opcodes ne soient pas redéfinis car ils sont en usage actif chez une entité autre qu'Intel ou AMD. Dix indices, allant du contournement des caches d'instructions L0 et L1 jusqu'à la transformation du vidage en simple écriture différée, décrivent un comportement de cache qu'aucun produit x86 public ne possède. C'est le troisième message de ce type depuis octobre 2025, et le fondeur n'a toujours pas de nom.
The short answer
Christian Ludloff, qui maintient la référence x86 sandpile.org, a publié le 29 août 2026 sur la liste de diffusion du noyau Linux une série d'indices de cache pour WBINVD, transmis au nom d'une entité autre qu'Intel ou AMD, en demandant que ces encodages ne soient pas redéfinis. Ces indices permettent à l'instruction de sauter les caches d'instructions L0 et L1, les caches de données L0 et L1, ou le cache de dernier niveau, et l'un d'eux transforme le vidage en écriture différée sans invalidation. C'est la troisième divulgation du genre, après des allocations de CPUID et de MSR en octobre 2025 et une description AMX à 16 et 32 tuiles en juillet 2026. Aucun produit, aucun nom, aucune annonce.
Deux entreprises vendent des processeurs x86 que vous pouvez acheter en magasin. Depuis dix mois, quelqu'un dépose des dossiers pour une troisième, et refuse de dire laquelle.
L'instruction, et les indices qu'on lui greffe
WBINVD est l'une des instructions les moins subtiles de l'architecture. Elle réécrit en mémoire chaque ligne de cache modifiée, puis invalide les caches de haut en bas, cache de dernier niveau partagé compris. Les noyaux y recourent quand la mémoire doit devenir cohérente avec quelque chose situé hors du domaine de cohérence, ou avant une transition d'alimentation qui videra les caches. Elle est correcte, elle est privilégiée, et elle coûte assez cher pour que les hyperviseurs passent des années à éviter de l'exécuter pour le compte de leurs invités.
Le message du 29 août décrit des indices qui permettent d'indiquer quelles parties de ce travail sauter. Le préfixe 0x67 laisse intacts les caches d'instructions L0 et L1. Le préfixe 0x66 fait de même pour les caches de données L0 et L1. 0xF2 saute le cache de dernier niveau, c'est à dire la partie coûteuse. 0xF3 saute l'invalidation, et il reste alors une écriture différée qui laisse les lignes valides en cache, ce qui constitue une opération réellement différente et non une version moins chère de la même.
Les six préfixes de segment, ES, CS, SS, DS, FS et GS, portent six autres significations propres à l'implémentation, non détaillées. Comme les préfixes se combinent, un WBINVD muni de tous ses indices peut occuper douze octets, pas loin du plafond de quinze octets par instruction. La demande jointe était simple : ces encodages sont en usage, ne les redéfinissez pas.
Ce qui a précédé
C'est le troisième message de la série, et les deux premiers étaient plus consistants.
En octobre 2025, Ludloff avait relayé des allocations d'opcodes pour la même entité anonyme, dont des feuilles CPUID dans la plage E000_xxxx et des plages de MSR correspondantes. Réserver une plage de feuilles CPUID, c'est ce que l'on fait quand on a des fonctions architecturales à énumérer, pas quand on expérimente.
Puis, le 27 juillet 2026, est arrivé le message intéressant. L'AMX d'Intel offre huit registres tuiles, chacun pouvant contenir seize lignes de soixante quatre octets, soit un kilo octet par tuile et huit kilo octets d'état architectural par fil d'exécution. Le message décrivait des implémentations à seize et trente deux tuiles. Seize entre dans les encodages VEX existants, en adressant TMM0 à TMM15, et la structure TILECFG contient déjà des champs pour seize tuiles que le matériel Intel laisse simplement inutilisés. Trente deux exige des encodages EVEX et fait passer TILECFG de soixante quatre à cent vingt huit octets.
Trente deux kilo octets d'état de tuiles par fil d'exécution, cela fait beaucoup de contexte à sauvegarder et à restaurer. Cela désigne une puce conçue autour du calcul matriciel plutôt qu'un cœur généraliste doté au passage d'une unité matricielle, et le message précisait que les logiciels supposant huit kilo octets tourneraient simplement en mode dégradé.
Le problème de l'attribution
La question évidente n'a pas de réponse confirmée. Chips and Cheese en a proposé la tentative publique la plus soignée, centrée sur RosaicLabs, société immatriculée au Delaware en mai 2026 et dirigée par Amarjit Gill, cadre du semiconducteur qui a travaillé avec l'actuel patron d'Intel, Lip Bu Tan, chez Rivos. Reuters et SemiAccurate rapportent qu'Intel a confié à RosaicLabs le code RTL de ses cœurs Atom, ce qui constituerait une vraie rupture pour une entreprise qui garde jalousement ses licences x86 et ses conceptions de cœurs depuis des décennies.
L'ennui, c'est le calendrier. La première publication mystérieuse date d'octobre 2025, sept mois avant l'existence administrative de RosaicLabs, et Chips and Cheese écrit clairement qu'aucune source publique ne relie la société à cette implémentation. Disposer du RTL d'Atom ne donne pas non plus un moteur matriciel à trente deux tuiles. Zhaoxin, Hygon, les grands hébergeurs qui conçoivent leur propre silicium, et ce qui subsiste de la lignée Centaur restent tous plausibles. Bonne histoire, fin inconnue.
Pourquoi cela finit sur votre bureau
Si vous maintenez quoi que ce soit qui décode du x86, c'est précisément le but de l'exercice. Objdump, perf, Valgrind, QEMU, Bochs, les outils de couverture et tous les analyseurs de traces maison ont un avis sur le sens d'une combinaison de préfixes. Quand deux parties attribuent un sens aux mêmes octets, la correction est pénible et arrive tard.
Pour les autres, c'est un signal à garder en tête. Le duopole x86 est stable depuis si longtemps que la plupart des plans de capacité le supposent sans le dire, de la même façon qu'IBM plaçant des instructions Arm dans un cœur de mainframe ou Samsung déplaçant des unités MAC dans la LPDDR5X bousculaient des hypothèses que plus personne n'examinait. Qui réserve de l'espace d'opcodes avec cette conviction compte livrer quelque chose. Nous n'avons simplement pas encore le droit de savoir quoi.
Sources et pour aller plus loin
- Another x86 Advisory From Some Entity Other Than Intel Or AMD, Phoronix, 29 août 2026
- Ten New x86 WBINVD Prefixes Hit the Kernel List, From a Vendor That Isn't Intel or AMD, Hardware Busters
- RosaicLabs, Atom RTL, and 32-Tile AMX: Trying to Piece Together a x86 Puzzle, Chips and Cheese
- sandpile.org, la référence x86 maintenue par Christian Ludloff
Questions fréquentes
Que fait réellement l'instruction WBINVD ?
WBINVD réécrit en mémoire toutes les lignes de cache modifiées, puis invalide les caches. C'est une instruction privilégiée et brutale, utilisée surtout quand le noyau doit rendre la mémoire cohérente avec quelque chose qui ne participe pas à la cohérence de cache, par exemple un périphérique qui fait du DMA hors du domaine cohérent, ou un processeur qui entre dans un état d'économie où le contenu des caches sera perdu. Comme elle parcourt toute la hiérarchie, cache de dernier niveau compris, elle est lente et elle pénalise tous les autres cœurs qui partagent ce cache. D'où l'intérêt, pour un fondeur, de pouvoir sauter les parties inutiles.
Quels sont ces nouveaux indices, concrètement ?
Ce sont des octets de préfixe accrochés à l'instruction. Le préfixe 0x67 demande au processeur de laisser tranquilles les caches d'instructions L0 et L1, 0x66 fait de même pour les caches de données L0 et L1, 0xF2 saute le cache de dernier niveau, et 0xF3 saute l'étape d'invalidation, si bien que l'opération devient une simple écriture différée qui laisse les lignes valides. S'y ajoutent les six préfixes de segment ES, CS, SS, DS, FS et GS, porteurs de significations propres à l'implémentation qui n'ont pas été détaillées. Les préfixes se combinent, ce qui explique qu'une instruction d'un octet puisse en occuper jusqu'à douze.
Est ce un processeur que l'on pourra acheter ?
Non. Rien n'a été annoncé, aucun nom de produit n'existe, et le fondeur n'est identifié dans aucune des publications. Ce que nous avons, c'est une demande de ne pas réutiliser cet espace d'opcodes, ce qui suppose du silicium, ou au minimum une conception assez avancée pour que changer l'encodage coûte cher. Le message de juillet 2026 allait plus loin en affirmant que l'implémentation matricielle élargie tournait à grande échelle depuis un certain temps, mais cette formule peut aussi bien désigner de la simulation, de l'émulation ou des prototypes sur FPGA que des puces de série.
Pourquoi publier cela sur la liste du noyau plutôt que dans un manuel ?
Parce que le noyau et la chaîne d'outils GNU sont l'endroit où l'espace d'opcodes x86 est effectivement occupé. Si binutils, le décodeur du noyau ou un émulateur attribue un sens à une combinaison de préfixes déjà utilisée par du matériel, les deux définitions entrent en collision et quelqu'un devra démêler cela des années plus tard. Publier sur la liste permet de poser une revendication sans annoncer de produit. Cela touche aussi directement les mainteneurs de désassembleurs, c'est à dire le public qui, autrement, afficherait n'importe quoi la première fois qu'une de ces instructions apparaîtra dans une trace.
Qui se cache derrière, alors ?
Personne ne le sait publiquement. Chips and Cheese a construit un faisceau d'indices autour de RosaicLabs, société immatriculée au Delaware en mai 2026 et dirigée par Amarjit Gill, ancien de Rivos, à qui Reuters indique qu'Intel a donné accès au code RTL de ses cœurs Atom. Le calendrier ne colle pas parfaitement, puisque la première publication mystérieuse précède cette immatriculation de sept mois, et la même analyse cite Zhaoxin, Hygon, les grands hébergeurs et l'ancienne lignée Centaur comme alternatives. À considérer comme une question ouverte, pas comme une conclusion.