Un bref message sur la liste du kernel de Linux a déclenché toutes les alarmes : certaines plages d’opcodes, feuilles CPUID et plages de MSR sur x86 sont “activement utilisées par une entité corporative autre qu’Intel et AMD”. Cette alerte est signée par Christian Ludloff, responsable de Sandpile.org, qui demande aux gestionnaires d’instructions, feuilles et registres d’éviter toute collision future. En clair : quelqu’un — ni Intel ni AMD — réserve et utilise des espaces de l’ISA sur x86.

Au-delà de la curiosité sur “qui ?”, cette alerte a des conséquences immédiates pour le noyau, les compilateurs, binutils, hyperviseurs et, par extension, pour tout logiciel interagissant avec CPUID ou MSR. À moyen terme, elle soulève aussi des questions sur lelicence, la compatibilité et la gouvernance d’une ISA qui, depuis des décennies, a été sous la tutelle de deux acteurs de facto.

Ce que dit (et ce qu’il ne dit pas) l’avertissement de Sandpile

Le courriel liste, sans attribuer de fabricant, les espaces déjà considérés comme occupés :

• Opcodes :
  • 0Eh en PM64 (l’ancienne instruction PUSH CS retirée avec x86-64 en 2002).
  • 0Fh,36h et 0Fh,3Eh (collision historique avec Cyrix RDSHR, aujourd’hui sans problème).
  • Groupe 0Fh,3Ah,E0h–EFh dans les codages classic, VEX, EVEX, Map3 et Map7, sans préfixes (ni segment overrides, LOCK, REPE/REPNE, ASIZE/OSIZE/REX ; REX2 exclu). Note : collision historique avec K10M VCVTFXPNTPD2DQ en MVEX E6h F2, sans problème non plus.
  • 0Fh,1Eh,/0 comme groupe de hinting NOP.
• CPUID : plage E000_xxxxh (valeurs encore non documentées).
• MSR : plage E000_xxxxh, avec une sémantique “non spécifiée après RESET” et “sans changement après INIT”.

Rien d’autre. Pas de vendor string, pas d’identifiants PCI, pas de steppings. Mais une instruction claire : n’utilisez pas ces plages.

Pourquoi c’est important : compatibilité binaire et discipline d’attribution

Sur x86, trois mécanismes assurent la compatibilité de bas niveau :

• Opcode : le code binaire de l’instruction (ex. 0x90 = NOP).
• CPUID : flags de fonctionnalités et feuilles qui annoncent les capacités (et, dans de nombreux cas, fixent des contrats ABI).
• MSR : registres spécifiques au modèle (Model-Specific Registers) pour gestion thermique, mode turbo, performance, etc.

La coexistence de plusieurs implémentations exige de la discipline :

• Un même opcode ne peut pas signifier différentes choses en silicium moderne si l’on souhaite que assembleurs, débogueurs et JITs fonctionnent.
• CPUID doit annoncer (et permettre le gating) de nouvelles features ; utiliser des feuilles “créatives” trompe les détecteurs.
• Les MSR hors contrat embrouillent le Système d’Exploitation, le BIOS, et hyperviseurs s’ils ne sont pas modélisés correctement.

D’où l’importance que Sandpile serve de registre de facto pour les zones “réservées / sans collision” et que le kernel et binutils anticipent pour éviter des dégâts.

Qui pourrait être derrière ? (et quelles implications)

Deux hypothèses plausibles – et pas mutuellement exclusives :

1. Héritage VIA / Cyrix
   • VIA Technologies a été historiquement le troisième licencié de l’architecture x86 (via Cyrix/IDT/NS).
   • Zhaoxin (JV en Chine avec Shanghai) développe des CPU x86 pour son marché basé sur la licence VIA.
   • Ce linéage contractuel est difficile à faire disparaître et correspond à “une entité différente d’Intel/AMD”.
2. Licence restreinte / design house
   • Un acteur disposant d’une licence limitée (militaire/embarquée) en déployant silicium à usage spécifique et en fixant des extensions privées.
   • Moins probable, mais envisageable : accords croisés en milieu fermé (semi-custom) nécessitant déploiement public pour éviter collision.

Et legalement ? Intel et AMD ont des accords croisés ; Intel contrôle la propriété intellectuelle de l’ISA et a octroyé des licences sélectives par le passé. VIA est l’exception classique. Tout acteur tiers solide sur x86 passe probablement par VIA/Zhaoxin (ou des dérivés) ou par licences spécifiques.

Impact immédiat pour kernel, toolchains et virtualisation

1. Attribution d’instructions / assembleurs
   • Réserver dans binutils/LLVM ces plages comme “non émettables” jusqu’à clarification.
   • Éviter que JITs et générateurs de code les utilisent heuristiquement.
2. Détection des features
   • Renforcer la détection CPUID : gating positif (flags de features) plutôt que “deviner par vendor + stepping”.
   • Accepter que des feuilles en E000_xxxxh existent et ne pas supposer que “espace haut = libre”.
3. MSR
   • Liste blanche stricte : accès hors contrat aux MSR doit échouer avec élégance (et pas provoquer #GP ou blocages).
   • Dans hyperviseurs, modélisation conservatrice ; si pas émulé, passe à travers avec capacités bien documentées ou bloque.
4. Outils de perf et PMU
   • Les compteurs et events liés à MSR peuvent échouer si le silicium n’est pas Intel/AMD. Fournir des routes de compatibilité.

Est-ce bien ou mal qu’un “tiers x86” entre en scène ?

Tout dépend de l’angle :

• Pro-concurrence : un nouvel acteur qui implémente l’ISA peut apporter plus d’offre, innovation (par ex., extensions axées sur la sécurité / IA) et pression sur les prix.
• Complexité : cela pourrait conduire à une fragmentation de l’ISA (extensions privées, sémantiques différentes), plus de branches de code et davantage de tests pour les tooling.
• Risques géopolitiques : si l’acteur est soumis à des réglementations hors communauté ou à des contrôles d’export, cela crée des zones grises de conformité et support dans les marchés occidentaux.
• Légal : toute collision “de facto” avec des contrats x86 existants peut entraîner une procédure; mieux mesurer ce risque avant de déployer des extensions.

Ma lecture pragmatique : l’équilibre entre concurrence et cohérence de plateforme pourra être maintenu si (1) le nouvel acteur publie des sémantiques et flags de fonctionnalités, (2) on maintient des contrats ABI stricts et (3) toolchains / OS évoluent disciplinément. Sans cela, on augmente la diversité au prix d’endettement technique.

Que faire aujourd’hui si vous gérez kernel, toolchain ou runtime

• Consolidez ces plages : marquez dans binutils/LLVM le groupe 0Fh,3Ah,E0h–EFh, 0Fh,36h/3Eh, 0Fh,1Eh,/0 et 0Eh PM64 comme réservés.
• CPUID : renforcez la détection par feature flag et préparez-vous aux feuilles E000_xxxxh.
• MSR : établissez une liste blanche stricte et gérez prudemment #GP ; en hyperviseurs, privilégiez le passe à travers conditionnel ou bloquez.
• Tests : si vous avez accès à Zhaoxin/VIA, ajoutez des tests de CPUID/MSR/PMU à votre infrastructure d’intégration continue.
• Documentation : référencez l’entrée de Sandpile dans vos guides de contribution pour éviter que des propositions pour ces plages “libres” soient faites à nouveau.
• Utilisateurs finaux : évitez l’utilisation de binaries qui “fingerprint” par vendor/stepping pour activer des chemins AVX/AMX ; privilégiez toujours les flags de fonctionnalités.

Scénarios (de plus probable à moins probable)

1. Zhaoxin (via VIA) occupe des plages pour extensions internes : cohérent avec sa feuille de route en Chine.
2. Un autre licencié semi-sur-mesure (défense/industriel) fixe MSR/CPUID pour son environnement et doit éviter toute collision.
3. Un acteur sans licence “tente sa chance” : peu probable en volume ; conformité des fondeuses et contrôles d’export rendraient cette option difficile.
4. Test de fumée / smoke test : improbable étant donné le ton et les antécédents de Sandpile.

Et si cela perturbe le userland ?

Le vrai risque ne réside pas dans le code portable de haut niveau, mais dans :

• JITs et assemblers générant des schémas non documentés.
• Outils de débogage / profilage manipulant MSR/PMU.
• Micro-optimisations confondant sémantiques VEX/EVEX avec de nouveaux schémas.
• VM / containers avec détecteurs CPUID “laxistes” qui supposent Intel/AMD.

Auditer ces zones avec des contrôles de cohérence et une détection robuste des fonctionnalités permet d’éviter les mauvaises surprises.

Conclusion : principes clés pour les équipes systèmes et tooling

• Fait : certains espaces ISA x86 sont déjà occupés par un tiers ; évitez de les utiliser.
• Pratique : renforcer la détection par feature flag et établir des listes blanches pour les MSR ; documenter soigneusement le périmètre E000_xxxxh.
• Écosystème : une plus grande diversité peut être positive si elle est accompagnée de documentation et de discipline ; sinon, elle peut apporter de la friction supplémentaire.
• Prudence : il ne faut pas prendre des risques inconsidérés — cet email ne parle pas d’un produit commercial imminent, mais d’une utilisation active à respecter pour éviter les collisions.

En fin de compte, en x86, la clé est toujours la compatibilité par contrat. Si les nouveaux acteurs jouent le jeu selon des règles claires, la compétition peut être saine et cohérente. Sinon, l’écosystème — kernel, toolchains, hyperviseurs — a montré qu’il sait amortir les frictions sans compromettre la stabilité.

Appendice : dictionnaire rapide

• Opcode : valeur binaire identifiant une instruction.
• CPUID : instruction renvoyant des feuilles avec flags de fonctionnalités.
• MSR (Model-Specific Register) : registres de contrôle propres à chaque modèle de CPU.
• VEX/EVEX/MVEX : préfixes/codages pour instructions vectorielles et étendues (SSE/AVX/AVX-512, etc.).
• PM64 : mode protégé 64 bits.
• Hinting NOP : NOPs avec sémantique “indicateur” pour les décodeurs/pipelines.

Sources : spinics.net et elchapuzasinformatico.