Does a third manufacturer enter x86? What does the Sandpile warning mean for kernel, toolchains, and the future of the platform

A brief message on the Linux kernel mailing list has set off all alarms: certain opcode spaces, CPUID leaves, and x86 MSR ranges are “actively in use by a third-party entity besides Intel and AMD.” The warning is signed by Christian Ludloff, head of Sandpile.org, and explicitly urges instruction, leaf, and register assigners to avoid future collisions. In plain terms: someone other than Intel or AMD is reserving and using ISA space on x86.

Beyond the curiosity of “who is it?”, the notice has immediate implications for core, compilers, binutils, hypervisors, and, by extension, any software interacting with CPUID or MSR. And, medium term, it raises questions about licensing, compatibility, and the governance of an ISA that has been historically guarded by two de facto custodians for decades.

What the Sandpile notice says (and what it doesn’t)

The email lists, without assigning a manufacturer, the spaces that are already considered occupied:

• Opcodes:
  • 0Eh in PM64 (the old PUSH CS instruction removed with x86-64 in 2002).
  • 0Fh,36h and 0Fh,3Eh (historic collision with Cyrix RDSHR, now non-issue).
  • Group 0Fh,3Ah,E0h–EFh in classic, VEX, EVEX, Map3, and Map7 encodings, without prefixes (no segment overrides, LOCK, REPE/REPNE, ASIZE/OSIZE/REX; REX2 excluded). Note: historical collision with K10M VCVTFXPNTPD2DQ in MVEX E6h F2, also non-problematic.
  • 0Fh,1Eh,/0 as a hinting NOP group.
• CPUID: range E000_xxxxh (values not yet documented).
• MSR: range E000_xxxxh, with semantics “unspecified after RESET” and “unchanged after INIT”.

Nothing else. No vendor string, no PCI identifiers, no steppings. But there is a clear instruction: don’t use these gaps.

Why it matters: binary compatibility and assignment discipline

In x86, three mechanisms underpin low-level compatibility:

• Opcode: the binary code of the instruction (e.g., 0x90 = NOP).
• CPUID: feature flags and leaves that announce capabilities (and, in many cases, establish ABI contracts).
• MSR: model-specific registers (Model-Specific Registers) for thermal control, turbo, performance, etc.

The coexistence of multiple implementations demands discipline:

• A single opcode cannot mean different things in contemporary silicon if we expect assemblers, debuggers, and JITs to work.
• CPUID must announce (and allow gating) for features; using “creative” leaves breaks detector mechanisms.
• MSR outside of agreed-upon ranges confuses OS/BIOS/hypervisors unless properly modeled.

Therefore, Sandpile acts as a de facto register for “reserved/non-collision” zones, and the kernel and binutils react preemptively to prevent damage.

Who might be behind this? (and what are the implications)

There are two plausible—and not mutually exclusive—paths:

1. Heritage from VIA / Cyrix
   • VIA Technologies is historically the third licensee of x86 (through Cyrix/IDT/NS).
   • Zhaoxin (a JV in China with Shanghai) develops x86 CPUs for its market based on VIA licensing.
   • This contractual lineage is difficult to revoke and aligns with “a corporate entity other than Intel/AMD.”
2. Restricted license / design house
   • An actor with limited licensing (defense/embedded) intentionally moving silicon with private extensions.
   • Less likely but possible: cross agreements in closed environments (semi-custom) that now require public announcements to avoid collisions.

Legally? Intel and AMD maintain cross agreements; Intel controls the intellectual property of the ISA and has licensed selectively in the past. VIA is the classic exception. Any sustainable third-party in x86 likely proceeds via VIA/Zhaoxin (or derivatives) or through specific sub-licenses.

Immediate impact on kernel, toolchains, and virtualization

1. Instruction assignment / assemblers
   • Reserve these gaps in binutils/LLVM as “non-emittable” until semantics are clarified.
   • Prevent JITs and code generators from heuristically using them.
2. Feature detection
   • Strengthen CPUID detection: do positive gating (feature flags) rather than guessing via vendor + stepping.
   • Accept that there will be leaves in E000_xxxxh and do not assume high space = free.
3. MSR
   • Implement strict whitelists: accesses outside the authorized range should fail gracefully (avoiding #GP or hangs).
   • In hypervisors, model conservatively: if not emulated, pass through with well-documented capabilities or block.
4. Performance tools / PMUs
   • Counters and events linked to MSRs may fail if the silicon isn’t from Intel/AMD. Provide compatibility pathways.

Is it good or bad if a “third-party x86” enters?

It depends on the perspective:

• Pro-competition: a new implementer of the ISA can bring more supply, innovation (e.g., security/AI extensions), and pricing pressure.
• Complexity: opens the door to ISA fragmentation (private extensions, different semantics), more code branches, and increased testing for tooling.
• Geopolitical risk: if the actor is subject to non-EU regulations or export controls, there will be grey areas in compliance and support in Western markets.
• Legal: any “de facto” collision with existing x86 contracts could lead to litigation; assess the risk before adopting new extensions.

My pragmatic takeaway: the balance between competition and platform coherence will be maintained if (1) the new actor publishes semantics and feature flags, (2) ABI contracts are strictly maintained, and (3) toolchains/OS are disciplined in updates. Without this, diversity will increase at the cost of technical debt.

What to do today if you maintain kernel, toolchain, or runtime

• Freeze these opcodes: mark in binutils/LLVM the group 0Fh,3Ah,E0h–EFh, the 0Fh,36h/3Eh, the 0Fh,1Eh,/0, and 0Eh PM64 as reserved.
• CPUID: reinforce feature flag detection and prepare for E000_xxxxh leaves.
• MSR: enforce a strict whitelist and handle #GP gracefully; in hypervisors, pass-through conditioned or block.
• Testing: if you have access to Zhaoxin/VIA, add CPUID/MSR/PMU tests to your CI farm.
• Documentation: link to the Sandpile entry in contribution guides so no one proposes these gaps “thinking they’re free”.
• End users: avoid binaries that “fingerprint” via vendor/stepping to activate AVX/AMX routes; always use feature flags.

Scenarios (most to least likely)

1. Zhaoxin (via VIA) occupies internal extension gaps: reasonable and aligned with their roadmap in China.
2. Another licensee with semi-custom (defense/industrial) fixing MSR/CPUID for their stack, aiming to avoid collisions.
3. An unlicensed actor “testing the waters”: unlikely in volume; compliance and export controls would short-circuit this route.
4. Decoy / smoke test: improbable given Sandpile’s tone and track record.

What if this breaks userland?

The real risk lies not in high-level portable code but in:

• JITs and assemblers emitting undocumented patterns.
• Debugging/profiling tools touching MSR/PMU.
• Micro-optimizations confusing VEX/EVEX semantics with new mappings.
• VMs/containers with lax CPUID detectors assuming Intel/AMD.

Auditing these areas with sanity checks and robust feature detection can prevent surprises.

Conclusion: Takeaways for system teams and tooling

• Fact: ISA space on x86 is already occupied by third parties; avoid these gaps.
• Practical: enhance feature flag detection and MSR whitelist; document the range E000_xxxxh as “owned”.
• Eco-system: increased diversity in x86 can be beneficial if documented and disciplined; otherwise, it increases friction.
• Caution: let’s not explode the bubble—this mail doesn’t hint at imminent commercial products but rather active use we must respect to avoid conflicts.

As always with x86, compatibility by contract remains key. If the third party plays by clear rules, we will have competitiveness without sacrificing coherence. Otherwise, the ecosystem—kernel, toolchains, hypervisors—has already shown resilience to edge cases without sacrificing stability.

Appendix: Quick Glossary

• Opcode: binary value identifying an instruction.
• CPUID: instruction returning leaves with feature/capability info.
• MSR (Model-Specific Register): CPU model control registers.
• VEX/EVEX/MVEX: prefixes/encodings for vector and extended instructions (SSE/AVX/AVX-512, etc.).
• PM64: 64-bit protected mode.
• Hinting NOP: NOPs with “clue” semantics for decoders/pipelines.

Sources: spinics.net and elchapuzasinformatico