80386 Microcode Disassembled: 215 Entry Points, Security Bug Found
After the 8086 microcode was disassembled, the 80386 remained a black box. Now, a collaborative effort has cracked it open. The 80386 microcode ROM contains 94,720 bits — nearly 9x the 8086's 10,752 bits. The team extracted the binary from a high-resolution die image using image processing and AI, then painstakingly decoded the micro-operations (μ-ops).
Microcode Structure and Instruction Count
The microcode has 215 entry points from the decoding ROM, compared to 60 on the 8086. This increase comes from new instructions and separate routines for register vs. memory operands, real vs. protected mode, and REP prefixes. Unlike the 8086 (and modern CPUs), the 80386 always executes a μ-op — there's microcode for every instruction.
Security Bug: I/O Permission Bitmap Flaw
The disassembly reveals a possible flaw in the I/O permission bitmap handling. When a 4-byte port access occurs at the edge of allowed I/O space, the microcode checks permission bits for only the first three addresses. This could allow the final byte to erroneously succeed, potentially granting user-mode processes unintended hardware access. The bug may have existed for over 40 years, though it's unclear if it affects all steppings.
No Easter Eggs, but Undocumented ICE Support
The microcode contains routines for interaction with In-Circuit Emulator (ICE) hardware used for low-level debugging. No hidden opcodes or Easter eggs were found, except a routine (0x849-0x856) that resembles the page fault handler but sets CR2 to a mysterious value — possibly unused.
Hardware Accelerators and Microcode Roles
The 80386 achieves higher per-cycle performance by hardware-accelerating algorithms that the 8086 implemented in microcode. Microcode now sets up accelerators like the multiply/divide hardware, barrel shifter, and protection test unit. Figuring out these interfaces was a major challenge.
How the Disassembly Was Done
High-resolution die images from Ken Shirriff were processed by GloriousCow and Smartest Blob using image processing and AI to extract the binary. The team then identified patterns to group bits into μ-ops and fields. Ken traced die lines to understand connections. The instruction decoder (multiple PLAs) and protection test PLA were decoded in parallel.
Where to Get the Disassembly
The full disassembly is available on GitHub in the x86 microcode repository. Start with parts.txt for file descriptions, or microcode_10.txt for the raw disassembly.
Why This Matters
This work provides the first complete view of 80386 microcode, enabling deeper understanding of x86 architecture evolution. The potential I/O permission bitmap bug is a reminder that even ubiquitous hardware can harbor long-undiscovered flaws. For developers working on emulators, security research, or retrocomputing, this disassembly is a goldmine.
Technical Details
- Microcode ROM size: 94,720 bits
- Entry points: 215
- 8086 comparison: 60 entry points, 10,752 bits
- Bug: 4-byte I/O access only checks first 3 addresses in permission bitmap
- Unused routine: 0x849-0x856, possibly related to page fault but sets CR2 differently
- No microcode-less instructions: Every x86 instruction has microcode
Example: Understanding a μ-op
While not a code snippet per se, the disassembly reveals field layouts. For instance, a μ-op might have fields for source register, destination register, ALU operation, and immediate. The team identified patterns like a recurring sequence that signaled end-of-instruction.
Why It Matters
For developers working on x86 emulators, low-level debuggers, or security research, this disassembly provides the first complete map of 80386 microcode. The potential I/O permission bitmap bug is a concrete finding that could affect legacy systems. Understanding how microcode evolved from 8086 to 80386 illuminates the design tradeoffs that shaped modern CPUs.
Editor's Take
I've spent years reverse-engineering old hardware, and this project is a masterpiece of persistence. The fact that a 40-year-old CPU might have an I/O permission bug that no one caught is both chilling and fascinating. I'm already thinking about how to test this on real hardware — if you have a 386 system, try a 4-byte OUT at the boundary of your I/O bitmap. The microcode disassembly is a gift to the retrocomputing community, and I hope it inspires similar work on other chips.
Developer Insights
- If you're writing an 80386 emulator, use the disassembly to validate your microcode implementation.
- Security researchers: test the I/O permission bitmap bug on real hardware and document findings.
- Retrocomputing enthusiasts: explore the microcode to understand undocumented behaviors like ICE support.


