CPUMicrocodes VS Microcode

Even my Haswell-E processor has continued getting microcode updates, and runs Windows 11.

They have been sort of cracked, but it doesn't matter. The web or chain of trust of those updates from the vendor to the processor is what matters. They're at least CRC checked to prevent loading corrupt files.

https://ieeeaccess.ieee.org/featured-articles/reverseenginee...

https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...

https://github.com/platomav/CPUMicrocodes

Microcode in a cpu: It's already open source and is baked into a cpu. This is what is needed for a cpu to... cpu. (idk i'm not William Shockley)

Assuming that the microcode update files have been acquired (maybe from here or here?), bundled into a tgz as expected by pkg_add, and made available alongside other signed firmware packages, an OpenBSD install then needs to know to look for this firmware bundle.

For the Intel stuff you're talking about, there's three classes keys in play, two of which have been leaked, but not the one that allows you to impersonate Intel. What we have are the keys shipped on every actual system (that has been cracked, I think that's just for Goldmont), the symmetric encrypt/decrypt key (AES IIRC), and the public signing key to verify that it came from Intel. Intel's private keys behind the signature haven't been leaked.

Interestingly though, it turns out that AMD K10 microcode updates weren't signed and had only the laziest form of encryption, allowing some security researchers to make custom ucode updates using this toolchain they posted on github: https://github.com/RUB-SysSec/Microcode

From what little we know of recent designs (the best public documentation being the fantastic work to reverse engineer AMD K8 and K10 microcode here https://github.com/RUB-SysSec/Microcode ), I'd describe x86 microcode as particularly wide vertical microcode of 64 bit ops.

The bit width is more a heuristic. With horizontal microcode you can look at each group of bits and it's clear 'these three bits are the selection input to this mux', 'this bit is an enable for the buffer linking these two buses', etc. Vertical microcode in contrast is further decoded with bit fields having different meanings based on opcode style fields.

Pretty universally, OoO superscalar cores will use vertical microcode (or vertical microcode looking micro-ops in cores without microcode) because that's the right abstraction you want at the most expensive part of the design: the tracking of in flight and undispatched operations in the reorder buffer, and how the results route in the bypass network. Any additional wodtch there really starts to hit your power budget, and it's the wrong level for horizontal microcode because the execution units will make different choices on even how many control signals they want.

any chip that you can't physically inspect might have backdoors. and if a CPU has updatable microcode, it's possible to implement a backdoor in microcode. there's no way to make a verifiably safe CPU with the features you want.