--- title: "¿Un tercer fabricante entra en x86? Qué significa el aviso de Sandpile para kernel, toolchains y el futuro de la plataforma" description: "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 distin..." url: https://revistacloud.com/un-tercer-fabricante-entra-en-x86-que-significa-el-aviso-de-sandpile-para-kernel-toolchains-y-el-futuro-de-la-plataforma/ date: 2025-10-19 modified: 2025-10-19 author: "Silvia A. Feliz" image: https://revistacloud.com/wp-content/uploads/2025/10/amd-intel-x86.jpg categories: ["Análisis y opinión", "Noticias"] tags: ["AMD", "intel", "ISA", "x86"] type: post lang: es --- # ¿Un tercer fabricante entra en x86? Qué significa el aviso de Sandpile para kernel, toolchains y el futuro de la plataforma Un mensaje breve en la [lista del *kernel*](https://www.spinics.net/lists/kernel/msg5879780.html) 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: 1. **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”. 2. **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* 1. **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. 2. **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”. 3. **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**. 4. **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) 1. **Zhaoxin (vía VIA)** ocupa huecos para **extensiones internas**: razonable y alineado con su hoja de ruta en China. 2. **Otro licenciatario con *semi-custom*** (defensa/industrial) fija **MSR/CPUID** para su *stack* y necesita **evitar colisiones**. 3. **Actor sin licencia** “probando suerte”: poco probable en volumen; el *compliance* de *foundries* y *export controls* haría el camino **muy corto**. 4. **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*. vía: [spinics.net](https://www.spinics.net/lists/kernel/msg5879780.html) y [elchapuzasinformatico](https://elchapuzasinformatico.com/2025/10/empresa-desconocida-disena-arquitectura-cpu-x86/)