linux-kernel - x86 opcode/CPUID/MSR allocations

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAKSQd8WQDfSax83Fyja0Y_aF-jq+7qfOpDo3GU5bz-8wEVUA1A@mail.gmail.com>
Date: Tue, 14 Oct 2025 23:07:14 +0200
From: Christian Ludloff <ludloff@...il.com>
To: linux-kernel@...r.kernel.org
Subject: x86 opcode/CPUID/MSR allocations

If x86 opcode/CPUID/MSR allocations are not
of your concern, then you can stop reading.

-------------------- 8< -------------------

I was asked to relay this to binutils/LKML.

As of 2025, the following are in active use
by a corporate entity other than Intel/AMD.

Any collisions with them should be avoided.

- opcode 0Eh in PM64 - x86 PUSH CS that got
  removed by x86-64 in 2002; not used since

- opcode 0Fh,36h and opcode 0Fh,3Eh - there
  is a historic collision with Cyrix RDSHR,
  but that is not considered to be an issue

- opcode 0Fh,3Ah,E0h...EFh in classic, VEX,
  EVEX, Map3, and Map7 encodings, without a
  prefix, or CS/SS/DS/ES/FS/GS, LOCK, REPE/
  REPNE, or ASIZE/OSIZE/REX (but not REX2!)
  prefixes - a historic collision with K10M
  VCVTFXPNTPD2DQ (at MVEX opcode E6h prefix
  F2) exists but is not considered an issue

- opcode 0Fh,1Eh,/0 - a "hinting NOP" group

- CPUID range E000_xxxxh - unspecified leaf
  return values at this particular time

- MSR range E000_xxxxh - unspecified values
  after RESET - unchanged values after INIT

I have documented them at www.sandpile.org.

-------------------- 8< -------------------

--
C.