Links to various x86 microcode-related projects, with exception to Intel Atom unrelated to P6 microarchitecture.

Intel Atom - Goldmont

• github.com/chip-red-pill/uCodeDisasm↗
• github.com/chip-red-pill/glm-ucode↗
• pietroborrello.com/.../offensivecon_ucode.pdf↗
• github.com/pietroborrello/ghidra-atom-microcode↗
• github.com/pietroborrello/CustomProcessingUnit↗
• github.com/chip-red-pill/crbus_scripts↗
• github.com/chip-red-pill/udbgInstr↗
• github.com/712ccca9-0294-4352-b994-457977fd46b8↗

Intel 8086

• www.righto.com/2023/07/undocumented-8086-instructions.html↗
• www.righto.com/2022/11/how-8086-processors-microcode-engine.html↗
• www.reenigne.org/blog/8086-microcode-disassembled/↗
• patents.google.com/patent/US4363091A/en↗

Via C3

The VIA C3 processor has a unique instruction called ALTINST[9] (encoded as 0F 3F), which serves as an entry point to an undocumented alternate instruction set. To enable the alternate instruction set, the ALTINST bit must first be set to 1 in the Feature Control Register (FCR) via WRMSR. Once enabled, executing 0F 3F performs a near branch to CS:EAX while simultaneously switching the processor into an internal mode,

interpreting subsequent instructions as the microcode and bypassing standard privilege checks. Alternate instructions is encoded within an LEA [EAX+EAX+disp32] opcode sequence (0x8D8400XXXXXXXX), where the 32-bit displacement field (XXXXXXXX) contains the actual micro-operation. If disabled (ALTINST=0), executing the 0F 3F opcode triggers an Invalid Instruction (#UD) exception.

• datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemiah%20Datasheet%20R113.pdf↗
• en.wikipedia.org/wiki/Alternate_Instruction_Set↗
• www.bitsavers.org/components/viaTechnologies/C3-ais-appnote.pdf↗
• Christopher Domas. Hardware backdoors in x86 CPUs. Black Hat, 2018.
• Apparatus and method for limiting access to model specific registers in a microprocessor, December 25 2012. US Patent 8,341,419.
• Microprocessor that performs X86 ISA and arm ISA machine language program instructions by hardware translation into microinstructions executed by common execution pipeline, November 4 2014. US Patent 8,880,851.
• phrack.org/issues/72/17_md#article↗

AMD CPUIDs

AMD IBS

Instruction Based Sampling (IBS) mechanism in AMD microprocessors from Families 10h, 12h, 15h, 16h, and 17h. IBS is a hardware mechanism that samples a subset of all of the instructions going through a processor. For each sampled instruction, a large amount of information is gathered and saved off as a program runs.

• docs.amd.com/.../Introduction-to-IBS-Instruction-Based-Sampling↗
• docs.amd.com/r/en-US/57368-uProf-user-guide/IBS-Derived-Events↗
• github.com/AMDESE/amd-perf-tools↗
• github.com/jlgreathouse/AMD_IBS_Toolkit↗
• reflexive.space/zen2-ibs/↗
• sci-hub.box/10.1109/ISPASS.2010.5452049↗
• amd.com/.../amd/en/documents/archived-tech-docs/programmer-references/31116.pdf↗ (2013+)
• amd.com/.../programmer-references/50742_15h_Models_60h-6Fh_BKDG.pdf↗ (Excavator/Bristol Ridge A6)
• amd.com/.../documents/processor-tech-docs/programmer-references/56255_OSRR.pdf↗ (fam 17)

AMD K6

AMD's sixth-generation AMD-K6® processor is a high-performance CISC-on-RISC microprocessor based on NexGen advanced, six-issue RISC86® superscalar 32bit architecture. Microcode patches/updates are not possible on this CPU.

• en.wikipedia.org/wiki/AMD_K6↗
• US6336178 patentimages.storage.googleapis.com/a7/ab/95/8caa77bc3c8efd/US6336178.pdf↗
• Patent WO1997013195A1 Instruction decoder including emulation using indirect specifiers
• sci-hub.box/10.1109/ISSCC.1997.585321↗
• www.halfhill.com/byte/1996-1_amd-k6.html↗
• Bruce Shriver, Bennett Smith: The Anatomy of a High-Performance Microprocessor: A Systems Perspective
• www.ardent-tool.com/CPU/Docs_AMD.html↗

AMD K7, K8, K10

CPUIDs 00300F10-00300F10

K7 theoretically allows microcode patching (but see errata), K8 and newer have official microcode patches available.

• argp.github.io/public/133f02627cbd3771ad5d4b09729cfce7.pdf↗
• www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/koppe↗
• fiona.dmcs.pl/ak/2014_paper_microcode.pdf↗ (incl. K7)
• www.realworldtech.com/forum/?threadid=35566&curpostid=35566↗

There is an unpublished tool similar to p6patchtool+p6scrambler+p6dis capable of dumping various AMD K8 and newer microcode updates.

K7 patch

From errata:

AMD Athlon™ Processor Model 10 Revision A2

Normal Specified Operation. The processor should function properly after a microcode patch is loaded. Non-conformance. The processor has the patch RAM BIST function disabled. Since BIST is not run on the patch RAM, reliable operation of the patch RAM cannot be guaranteed. Therefore it should not be used. Potential Effect on System. When a microcode patch is loaded, the system may not behave properly. Suggested Workaround. Do not load a microcode patch.

application-notes.digchip.com/019/19-45009.pdf↗

K8/K10 patch structure

Only some fields are checked by the microcode loading routine. Some sources say GP is raised on faulty patch load, this was partially verified, but this might have been caused by faulty patch triads/seqw. Successful load takes > 1000 rdtsc cycles and also Patch ID MSR was updated accordingly.

AMD Bobcat / Bulldozer / Piledriver / Steamroller / Excavator

CPUIDs 00500F00 - 00670F00.

Structure of encrypted microcode updates is unknown, plaintext updates can be disassembled (CPUIDs 00580F00-00580F20). No RSA.

CPUIDs:

• Bulldozer (Family 15h, Models 00h–0Fh) 0x600F12 (Zambezi)
• Piledriver (Family 15h, Models 10h–1Fh) 0x610F01 (Trinity/Richland)
• Steamroller (Family 15h, Models 30h–3Fh) 0x630F01 (Kaveri)
• Excavator (Family 15h, Models 60h–6Fh) 0x660F01 (Carrizo / Bristol Ridge)

AMD unknown family

CPUIDs 0x00680F00-0x00690F00

Almost nothing is known about these CPUs. Microcode update is in plaintext, using tetrads + seqw, simple unknown checksum algorithm without RSA.

AMD Jaguar/Puma

CPUIDs 0x00700F00 - 0x00730F01

It is possible to disassemble, seems to be using only diads + seqw, patch seems to be using RSA signature with this modulus:

3F 86 AA D4  22 50 8B 28  79 D0 D5 A2  C8 DF D0 60
2E E0 82 4F  D9 9F 2F 84  A1 D5 67 BF  37 7A A6 CE
03 34 15 72  E2 40 F5 A1  64 61 68 3F  A6 33 F1 1B
22 20 E0 50  47 60 3B 5C  74 FB 66 CE  11 C5 DD 55
14 59 3A 74  AD 6F 6E F8  FE 58 50 1E  3B D0 33 83
CB F2 56 63  AC 9F 9C E4  26 2F 12 5F  9A C4 A7 5A
63 0E F6 A6  42 F3 25 08  AA 0B F8 77  49 80 F5 6E
AF 31 84 33  44 49 CD 02  84 E2 02 B7  15 3E 38 C8
5D 51 ED E1  A7 73 7A B5  3C F7 DC 41  66 CC 7F 69
CE 5F 70 A9  55 45 DA 55  BF 4E FB FD  F4 39 17 EE
4B 69 84 35  66 5D 87 2F  87 54 3A 87  22 C6 36 A6
14 77 E1 A6  ED 7E 01 EF  9F 41 23 AD  AD EE 38 D2
28 2F C9 AB  65 D2 42 E6  C0 37 8A 7D  6A B5 A0 9F
04 9D 9F F1  74 65 8B D4  94 E3 32 56  42 9C ED E8
6A 76 36 1E  28 EF E9 51  BC 26 57 6D  4A 1E 1D 73
C3 72 42 FF  F3 05 01 E8  12 25 D9 A3  42 E3 14 BD

AMD Zen ... Zen 5c

At a structural level, AMD microcode patch files follow a consistent format consisting of a header, patch payload, and cryptographic metadata. The header includes CPU identification fields (family/model/stepping), patch revision, and metadata such as date or patch ID. This is followed by the microcode body itself, which contains instructions for an internal RISC-like control engine used by the CPU. The final portion includes a public key and a signature that is supposed to authenticate the patch.

The critical weakness lies in how this signature is verified. Instead of a robust cryptographic hash, the design uses AES-CMAC in a way that permits controlled collisions. Because the verification effectively compares derived hashes of public key material, an attacker can modify the patch payload and adjust padding or additional blocks to preserve the expected hash value. This allows arbitrary changes to the microcode while still passing signature checks. The patch format itself is flexible enough to accommodate such modifications (e.g., inserting extra blocks), which is what makes the forgery practical.

• nvd.nist.gov/vuln/detail/CVE-2024-56161↗
• www.amd.com/en/resources/product-security/bulletin/amd-sb-3019.html↗
• github.com/.../blob/master/pocs/cpus/entrysign/zentool/docs/intro.md↗
• github.com/.../blob/master/pocs/cpus/entrysign/zentool/docs/reference.md↗
• github.com/google/security-research/tree/master/pocs/cpus/entrysign/zentool↗
• youyou.moe/2025/10/entrisign-matisse/↗
• www.youtube.com/watch?v=sUFDKTaCQEk↗
• bughunters.google.com/blog/zen-and-the-art-of-microcode-hacking↗
• reflexive.space/zen2-ibs/↗

RSA signature

2048bits, expoent 0x10001.

Older patches use modulus:

C7 9C 87 25  DE F5 D3 87  79 46 DF B6  28 95 A5 99
9B DB 84 2A  C5 8D 79 42  14 D8 FF 37  C8 FE 16 CC
38 35 82 3A  7B FC 9C 2D  F7 46 AE 2D  71 CA DB 67
F8 8A 35 3C  69 CA 45 97  E8 47 52 89  D3 0F 4D FD
54 EA 69 9A  35 CA 7D A2  7F FE C1 71  70 29 A3 5F
52 20 DE 4D  15 D0 85 8E  87 88 93 08  CB E6 4B 9C
00 AA D6 D0  DC 00 2A 6D  46 54 1A CA  08 2E 9D 11
27 16 29 AD  FA 91 5A 43  CC EC AD F7  87 54 3F 34
69 C5 6E 17  20 59 00 AA  FE 0B AA 89  4F 4F E4 41
AD 77 A3 7D  5B 1B A4 4F  59 79 5A 1E  2A 97 A4 4B
8C 3E D4 C4  4F D7 B6 F1  88 90 93 37  50 73 5A C2
73 1A 15 8A  43 79 8D BA  7D 19 BD 53  41 55 D9 5C
F2 12 3F A2  5E D2 10 48  61 2F 4C 22  9D 97 97 E5
D7 21 D2 38  1E 86 79 ED  E9 77 B8 D2  A0 80 F0 FC
B1 5F 1F B2  CA BC BB C2  85 5A 30 23  0A C1 D0 C6
5D A7 53 DD  CD 0F C9 1C  B9 60 74 F8  BA AD 80 C3

Newer patches use modulus:

98 93 86 B9  CC E0 F2 86  6B CE E6 A6  C1 08 F9 D9
3E 7F CB F6  A4 E2 DB 2B  2C 65 4C D2  D4 A9 55 14
B3 27 01 D9  3B E5 8C D2  CF A7 0A 58  5B 1D 16 B2
3B 11 EE 1E  F0 EC 69 F2  A5 1D F5 46  0A 91 CE 36
89 1C C3 4B  AB B5 3D A3  64 20 C4 30  03 02 9E 6A
59 B7 74 A5  68 61 F6 46  A6 03 3C 8F  CE 32 A9 94
C1 AC 63 11  74 79 6F F4  BA 42 07 4F  38 89 AC 55
21 5B 6C C5  33 8A 31 6B  5E C6 39 B8  00 D2 92 6A
BD 7F BF 24  12 8B 91 AC  B8 68 51 86  06 32 BD 30
C8 B0 2A BB  8A DD 72 31  08 77 19 1D  F5 41 82 2A
C8 17 86 77  C1 CF 2D 1D  4D 09 C4 FE  8E 91 47 2C
85 6E 3D 80  B7 E1 34 E1  AB E2 5D 92  D0 86 A5 EF
20 96 7E B8  4D 8F 98 27  6B 1C A6 97  D2 C8 D5 2D
EA FE 4E 2F  03 2F 2E 02  42 90 BA B1  F2 74 2C 54
69 DF 55 47  5A E3 61 58  24 8A C4 73  F2 73 E0 76
77 FC 42 5F  BD DF F1 16  56 A5 09 BF  31 19 7E 21

After doing modexp on signature, both used pubkeys reveal PKCS1 padded 16-byte (128bit) hash.

CMAC bug mitigation: www.amd.com/en/resources/product-security/bulletin/amd-sb-3019.html↗ (to be further analyzed how it applies to keys below and how they fixed the microcode via PSP; it seems the algorithms is changed to Merkle Damgard x Matyas-Meyer-Oseas)

EntrySign

The EntrySign vulnerability, as demonstrated by Google’s zentool research, is fundamentally a break in AMD’s microcode trust model. The issue stems from incorrect use of AES-CMAC during signature verification, allowing attackers with kernel-level access to forge valid signatures for modified microcode patches. In practice, this enables loading arbitrary microcode into the CPU—effectively bypassing AMD’s intended security boundary around firmware-level behavior. The zentool project shows this is not just theoretical: it provides tooling to parse, modify, reassemble, and re-sign microcode patches, demonstrating real modifications to CPU instructions.

The scope of affected processors is broad because the flaw exists in the shared microcode verification design used across the entire Zen lineage. Official confirmations and research indicate that all AMD Zen generations—from the original Zen through Zen 5—are impacted, including both consumer (Ryzen), server (EPYC), and mobile/APU parts. The vulnerability originates in how microcode updates are authenticated, so any CPU using that mechanism inherits the issue. Later disclosures confirmed that even newer Zen 5 silicon remains vulnerable, extending the impact across essentially all modern AMD CPUs built on the Zen architecture family.

Affected architectures:

• Zen (Family 17h, ~2017): Summit Ridge, Naples, Raven Ridge, Whitehaven
• Zen+ (~2018): Pinnacle Ridge, Colfax, Picasso
• Zen 2 (~2019): Rome, Matisse, Castle Peak, Renoir, Lucienne, Mendocino
• Zen 3 / Zen 3+ (~2020–2022): Milan, Vermeer, Chagall, Cezanne, Barcelo, Milan-X, Rembrandt
• Zen 4 / Zen 4c (~2022–2024): Genoa, Raphael, Storm Peak, Dragon Range, Phoenix, Bergamo, Siena
• Zen 5 / Zen 5c (~2024–2025): Granite Ridge, Turin, Strix Point, Fire Range, Shimada Peak

Transmeta Crusoe/Efficeon

A simple hardware core with its own native instruction set, and a software layer (Code Morphing Software, CMS) that makes the system appear like an x86 CPU. Instead of implementing the x86 instruction set directly in hardware, Crusoe executes a proprietary internal ISA and relies on CMS to dynamically translate x86 instructions into that native form at runtime. At the hardware level, Crusoe uses a VLIW (Very Long Instruction Word) architecture, where instructions are grouped into bundles (called molecules) containing multiple smaller operations (atoms). Each atom is roughly comparable to a simple RISC-like operation, and multiple atoms are issued together in a single wide instruction word (64- or 128-bit). This means the hardware itself is relatively simple: it executes explicitly parallel instruction bundles without doing complex scheduling, out-of-order execution, or branch prediction internally. Instead, those responsibilities are pushed into software. The key innovation is that the internal instruction set is not tied to x86 at all. The CMS layer acts as a dynamic binary translator and optimizer: it takes incoming x86 code, decodes it, and recompiles it into optimized sequences of native VLIW instructions. Frequently executed code paths are cached as translated blocks and progressively optimized, effectively behaving like a runtime JIT compiler specialized for the Crusoe core.

Because of this indirection, the native ISA can remain simple, regular, and RISC-like, while still supporting a complex external ISA such as x86.

From an instruction-set perspective, the native Crusoe ISA is characterized by:

• Fixed-width, RISC-like operations (“atoms”)
• Explicit parallel grouping into VLIW bundles (“molecules”)
• Software-controlled scheduling and register usage
• A relatively large register file managed by the CMS rather than exposed architecturally
• This design effectively turns the CPU into a software-defined processor. All complex behaviors traditionally implemented in hardware—such as instruction decoding, dependency analysis, instruction reordering, and even parts of exception handling—are implemented in CMS.

The consequence is a very small, power-efficient core, at the cost of relying heavily on sophisticated runtime translation software.

• en.wikipedia.org/wiki/Transmeta#Products↗
• theretroweb.com/.../crusoe-tm5700-tm5900-processor-6429903a6bb74624192317.pdf↗
• www.realworldtech.com/crusoe-exposed/↗
• classes.engineering.wustl.edu/cse362/images/c/c7/Paper_aklaiber_19jan00.pdf↗
• safari.ethz.ch/.../fetch.php?media=dehnert_transmeta_code_morphing_software.pdf↗
• www.cs.cornell.edu/courses/cs6120/2019fa/blog/transmeta/↗
• datasheets.chipdb.org/Transmeta/Crusoe/TM5800/TM5800_BIOSGuide_6-14-02.pdf↗
• linux-kernel.vger.kernel.narkive.com/.../crusoe-s-persistent-translation-on-l...↗
• www.xsim.com/papers/crusoe-talk-amasbt2009.pdf↗
• www.xsim.com/papers/crusoe-amasbt2009.pdf↗
• www.xsim.com/papers/transmeta-code-morphong-software.dehnert-cgo03.pdf↗
• www.xsim.com/papers/transmeta-scopes-2003.dehnert.pdf↗
• David R. Ditzel articles scholar.google.com/citations?user=wCpExhsAAAAJ&hl=en↗

---

The author is not affiliated with, endorsed by, or sponsored by Intel Corporation or its affiliates. All trademarks, including but not limited to Intel, Pentium, and any other registered or unregistered marks mentioned herein, are the property of their respective owners. Their use in this context is solely for descriptive and informational purposes and constitutes nominative fair use under applicable trademark laws.