¿Un tercer fabricante entra en x86? Qué significa el aviso de Sandpile para kernel, toolchains y el futuro de la plataforma

Silvia A. Feliz

Un mensaje breve en la lista del kernel de Linux ha encendido todas las alarmas: ciertos espacios de opcodes, hojas CPUID y rangos de MSR de x86 están “en uso activo por una entidad corporativa distinta de Intel y AMD.” La advertencia llega firmada por Christian Ludloff, responsable de Sandpile.org, y pide expresamente a quienes asignan instrucciones, hojas y registros evitar colisiones futuras. Traducido: alguien más—no Intel ni AMD—está reservando y usando espacio de ISA en x86.

Más allá del morbo de “¿quién es?”, el aviso tiene consecuencias inmediatas para núcleo, compiladores, binutils, hipervisores y, por extensión, para cualquier software que interactúe con CPUID o MSR. Y, a medio plazo, abre interrogantes sobre licenciamiento, compatibilidad y la propia gobernanza de una ISA que durante décadas ha tenido dos guardianes de facto.

Lo que dice (y lo que no) el aviso de Sandpile

El correo enumera, sin atribuir fabricante, los espacios que ya deben considerarse ocupados:

Opcodes:
- 0Eh en PM64 (el viejo PUSH CS retirado con x86-64 en 2002).
- 0Fh,36h y 0Fh,3Eh (colisión histórica con Cyrix RDSHR, hoy no problemática).
- Grupo 0Fh,3Ah,E0h–EFh en codificaciones classic, VEX, EVEX, Map3 y Map7, sin prefijos (ni segment overrides, LOCK, REPE/REPNE, ASIZE/OSIZE/REX; se excluye REX2). Nota: colisión histórica con K10M VCVTFXPNTPD2DQ en MVEX E6h F2, también no problemática.
- 0Fh,1Eh,/0 como grupo de hinting NOP.
CPUID: rango E000_xxxxh (valores aún no documentados).
MSR: rango E000_xxxxh, con semántica “no especificada tras RESET” y “sin cambios tras INIT”.

Nada más. No hay vendor string, no hay identificadores PCI, no hay steppings. Pero sí hay una instrucción clara: no uséis estos huecos.

Por qué importa: compatibilidad binaria y disciplina de asignación

En x86, tres mecanismos sostienen la compatibilidad de bajo nivel:

Opcode: el código binario de la instrucción (p. ej., 0x90 = NOP).
CPUID: feature flags y hojas que anuncian capacidades (y, en muchos casos, fijan contratos ABI).
MSR: registros específicos de modelo (Model-Specific Registers) para control térmico, turbo, perf, etc.

La coexistencia de múltiples implementaciones exige disciplina:

Un mismo opcode no puede significar cosas distintas en silicio contemporáneo si esperamos que ensamblados, depuradores y JITs funcionen.
CPUID debe anunciar (y permitir gating) de features nuevas; usar hojas “creativas” rompe detectores.
Los MSR fuera de contrato confunden SO/BIOS/hypervisores si no se modelan adecuadamente.

De ahí que Sandpile actúe como registro de facto para zonas “reservadas/no colisionables” y que el kernel y binutils reaccionen antes de que haya daños.

¿Quién podría estar detrás? (y qué implicaciones tiene)

Hay dos vías plausibles—y no excluyentes:

Herencia de VIA / Cyrix
- VIA Technologies es, históricamente, el tercer licenciatario de x86 (vía Cyrix/IDT/NS).
- Zhaoxin (JV en China con Shanghai) desarrolla CPU x86 para su mercado con base de licencia VIA.
- Ese linaje contractual es difícil de revocar y encaja con “una entidad corporativa distinta de Intel/AMD”.
Licencia restringida / design house
- Algún actor con licencia limitada (defensa/embebido) moviendo silicio de propósito especial y fijando extensiones privadas.
- Menos probable, pero posible: acuerdos cruzados en ámbitos cerrados (semi-custom) que ahora necesitan anuncios públicos para no colisionar.

¿Y legalmente? Intel y AMD mantienen acuerdos cruzados; Intel controla la propiedad intelectual de la ISA y ha licenciado selectivamente en el pasado. VIA es la excepción clásica. Cualquier tercer actor sostenible en x86 pasa casi seguro por VIA/Zhaoxin (o derivaciones) o por sub-licencias específicas.

Impacto inmediato para kernel, toolchains y virtualización

Asignación de instrucciones / ensambladores
- Reservar en binutils/LLVM estos huecos como “no emitibles” hasta conocer semántica.
- Evitar que JITs y generadores de código los usen por heurística.
Detección de features
- Endurecer detectores CPUID: gating positivo (feature flags) en lugar de “adivinar por vendor + stepping”.
- Aceptar que habrá hojas en E000_xxxxh y no suponer que “espacio alto = libre”.
MSR
- White-list estricto: accesos a MSR fuera de contrato deben fallar con gracia (y no provocar #GP o bloqueos).
- En hypervisores, modelado conservador de MSR; si no se emula, pasa-a-través con capabilities bien documentadas o bloquea.
Herramientas de perf y PMU
- Contadores y events ligados a MSR pueden fallar si el silicio no es Intel/AMD. Proveer rutas de compatibilidad.

¿Es bueno o malo que entre un “tercero x86”?

Depende del ángulo:

Pro-competencia: un nuevo implementador de la ISA puede traer más oferta, innovación (p. ej., extensions orientadas a seguridad/AI) y presión en precio.
Complejidad: abre la puerta a fragmentación de ISA (extensiones privadas, semánticas distintas), más ramas de código y más pruebas para tooling.
Riesgo geopolítico: si el actor está sujeto a normativas extracomunitarias o a controles de exportación, habrá zonas grises de cumplimento y soporte en mercados occidentales.
Legal: cualquier colisión “de facto” con contratos x86 existentes puede judicializarse; medir el riesgo antes de “aprovechar” extensiones nuevas.

Mi lectura pragmática: el equilibrio entre competencia y coherencia de plataforma se mantendrá si (1) el nuevo actor publica semánticas y feature flags, (2) se mantienen contratos ABI estrictos y (3) toolchains/OS se actualizan con disciplina. Sin esto, ganamos diversidad a costa de deuda técnica.

Qué hacer hoy si mantienes kernel, toolchain o runtime

Congelar esos opcodes: marca en binutils/LLVM el grupo 0Fh,3Ah,E0h–EFh, los 0Fh,36h/3Eh, el 0Fh,1Eh,/0 y el 0Eh PM64 como reservados.
CPUID: refuerza detección por feature flag y prepárate para hojas E000_xxxxh.
MSR: lista blanca estricta y manejo seguro de #GP; en hypervisores, pasa-a-través condicionado o bloqueo.
Pruebas: si tienes acceso a Zhaoxin/VIA, añade al farm de CI pruebas de CPUID/MSR/PMU.
Documentación: enlaza la entrada de Sandpile en guías de contribución para que nadie proponga esos huecos “porque parecen libres”.
Usuarios finales: evita binaries que “fingerprint” por vendor/stepping para activar rutas AVX/AMX; siempre feature flags.

Escenarios (ordenados de más a menos probables)

Zhaoxin (vía VIA) ocupa huecos para extensiones internas: razonable y alineado con su hoja de ruta en China.
Otro licenciatario con semi-custom (defensa/industrial) fija MSR/CPUID para su stack y necesita evitar colisiones.
Actor sin licencia “probando suerte”: poco probable en volumen; el compliance de foundries y export controls haría el camino muy corto.
Señuelo / smoke test: improbable dado el tono y el track record de Sandpile.

¿Y si esto rompe userland?

El riesgo real no está en el código portable de alto nivel, sino en:

JITs y assemblers que emiten patrones no documentados.
Herramientas de depuración/profiling que tocan MSR/PMU.
Micro-optimizaciones que confunden semánticas de VEX/EVEX con mapas nuevos.
VM/containers con detectores CPUID “flojos” que asumen Intel/AMD.

Auditar esas zonas con sanity checks y feature detection robusta evita sorpresas.

Conclusión: takeaways para equipos de sistemas y tooling

Hecho: hay espacios de ISA x86 ya ocupados por un tercero; evitadlos.
Práctico: reforzad detección por feature flag y listas blancas de MSR; documentad el rango E000_xxxxh como “propietario”.
Ecosistema: más diversidad en x86 puede ser buena si viene con documentación y disciplina; si no, suma fricción.
Prudencia: no elevemos el suflé—el correo no habla de producto comercial global inminente, sí de uso activo que debemos respetar para no chocar.

Como siempre en x86, la clave será compatibilidad por contrato. Si el tercer actor juega con reglas claras, ganaremos competencia sin perder coherencia. Y si no, el ecosistema—kernel, toolchains, hipervisores—ya ha demostrado que sabe amortiguar aristas sin sacrificar estabilidad.

Apéndice: diccionario rápido

Opcode: valor binario que identifica una instrucción.
CPUID: instrucción que devuelve hojas con features/capacidades.
MSR (Model-Specific Register): registros de control específicos del modelo de CPU.
VEX/EVEX/MVEX: prefijos/codificaciones para instrucciones vectoriales y extendidas (SSE/AVX/AVX-512, etc.).
PM64: modo protegido de 64 bits.
Hinting NOP: NOPs con semántica de “pista” para decoders/pipelines.