Yesterday we entered SMM, the secret firmware meeting room.

Today we go smaller.

Below the operating system.

Below firmware policy.

Below the instruction manual’s polite fiction.

We inspect microcode.

Microcode is one of the reasons a CPU can be sold as a fixed piece of silicon while still receiving patch notes like a live service game.

The processor is hardware.

The processor also has secrets.

I. The Fiction Of The Instruction Set

Software sees instructions:

mov rax, [rbx]
add rax, rcx
syscall

The instruction set architecture says what these instructions mean.

Inside the CPU, implementation is more complicated:

• decode
• micro-operations
• scheduling
• execution units
• speculation
• retirement
• exceptions
• memory ordering

Microcode participates in controlling internal behavior for some instructions and sequences, especially complex operations and errata workarounds.

The ISA is the law.

Microarchitecture is the bureaucracy.

Microcode is the classified memo explaining how the bureaucracy actually behaves.

II. Why Updates Exist

CPUs ship with errata.

This is not scandal.

This is engineering at nanometer scale under market pressure.

Microcode updates can correct or mitigate certain processor issues after manufacturing.

They cannot change arbitrary silicon into a new design.

They can adjust internal sequences, disable or modify features, add control bits, and implement workarounds for specific problems.

Microcode can often do	Microcode cannot magically do
mitigate defined errata	redesign the whole core
alter internal instruction behavior	add unlimited new hardware
expose control bits / MSRs	fix every timing side channel
support security mitigations	make bad architecture free
disable problematic features	make performance losses vanish

Microcode is a patch.

It is not reincarnation.

III. How It Loads

Microcode updates are commonly delivered by firmware during early boot and may also be loaded by the operating system.

The rough flow:

flowchart TB
    RESET["reset"]
    BASE["CPU starts with built-in microcode"]
    FW["firmware loads microcode update"]
    BOOT["bootloader / kernel starts"]
    OS["OS may load newer microcode"]
    RUN["system runs with patched behavior"]

    RESET --> BASE --> FW --> BOOT --> OS --> RUN

On Linux, administrators may see microcode packages such as:

dmesg | grep -i microcode

On BSDs and other systems, the mechanisms differ, but the principle remains:

load the update early,

preferably before the machine begins doing interesting damage.

IV. Volatile Patch, Permanent Problem

Microcode updates are often volatile.

They must be loaded after reset.

The CPU contains a baseline microcode state from manufacturing, then firmware or OS applies updates.

This is why firmware updates matter.

If the firmware includes newer microcode, the platform can apply fixes before the OS is fully alive.

If the OS loads microcode later, some early boot code may have already executed under older behavior.

The ideal state:

firmware loads early microcode
OS verifies or updates again
system runs with current mitigations

The bad state:

user never updates firmware
OS package missing
CPU erratum becomes local folklore

The Republic does not accept folklore as a patch strategy.

V. Spectre, Meltdown, And The Era Of Embarrassing Physics

Speculative-execution vulnerabilities made microcode visible to normal people.

Before that, microcode was mostly a thing kernel engineers, firmware teams, and people with opinions about dmesg cared about.

After Spectre-class disclosures, users learned that CPUs had:

• branch prediction behavior
• speculation controls
• new model-specific registers
• indirect branch controls
• performance costs attached to security

Microcode updates became part of public security response.

Not the whole response.

Part of it.

Operating systems also needed changes.

Compilers needed changes.

Applications sometimes needed changes.

The hardware had sinned in parallel.

The penance was distributed.

VI. Microcode And Trust

Microcode is proprietary on mainstream x86 CPUs.

Users generally cannot audit it.

They receive signed blobs from CPU vendors through firmware or OS packages.

This is uncomfortable but practical.

Trust question	Reality
Can users inspect all microcode behavior?	no
Are updates signed by vendors?	yes, on mainstream platforms
Can random users write custom x86 microcode?	no
Are updates important for security?	often
Is refusing updates automatically safer?	usually no

The owner faces an ugly choice:

trust opaque vendor patches,

or run known broken silicon behavior.

This is not freedom.

This is a hostage negotiation with errata.

VII. Microcode vs Firmware

People mix terms.

The Ministry corrects them.

Thing	Where it runs / lives
BIOS / UEFI	platform firmware on SPI flash
Intel ME / AMD PSP	separate management/security engines
SMM handler	firmware code in System Management Mode
microcode	CPU-internal control behavior loaded into processor
OS kernel	operating system core

Microcode is not UEFI.

Microcode is not Intel ME.

Microcode is not the kernel.

It is lower and stranger:

behavioral patching for the CPU itself.

VIII. The Real Story (Suppressed)

Officially, microcode means low-level control code inside the processor.

Suppressed expansion:

Miniature Regime Instructions Correcting Old Design Errors.

The first erratum was reportedly titled:

“Processor may produce incorrect result when user believes marketing.”

This was fixed in microcode revision 0x00000001.

The second erratum was:

“Speculation may reveal secrets.”

The patch note read:

“Performance may become honest.”

This caused panic in benchmark ministries worldwide.

IX. The Lesson

Microcode is the CPU’s hidden amendment process.

It lets vendors correct some mistakes after manufacturing, support security mitigations, and adjust internal behavior without replacing the chip.

But it also reminds us that the instruction set is not the whole machine.

The visible contract is implemented by invisible machinery.

The decree:

• CPUs have errata
• microcode updates matter
• firmware and OS both participate in loading them
• updates are usually opaque and vendor-signed
• microcode can mitigate, not perform miracles
• security fixes may cost performance because physics invoices everyone

This ends the first deep internals arc:

reset vector,

MMU,

page tables,

TLB,

cache coherency,

interrupts,

DMA/IOMMU,

SMM,

microcode.

The machine is no longer mysterious.

It is worse:

it is understandable.

— Kim Jong Rails, Supreme Leader of the Republic of Derails