Hacker News Reader

Comment by chacham15 | Hacker News Reader

When I read this, I expected there to be some discussion about the chain of custody, verification of the signature of microcode updates, or possible injection attacks, but none of that is mentioned here. I think those are the real reasons that people are afraid of microcode...even in the case that you trust the vendor themselves, you have little to no way of knowing that what you have itself hasnt been modified.

View on HN

They're signed and I believe encrypted by Intel. The CPU will fail to apply a microcode update whose signature fails validation. Here's the best public discussion about the format of microcode updates I know of offhand: http://www.inertiawar.com/microcode/

They have been partially reversed and ==maybe== definitely 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.

Intel microcode update secret key revealed

https://arstechnica.com/gadgets/2020/10/in-a-first-researche...

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

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

https://github.com/platomav/CPUMicrocodes

It would take state actor-level effort to install APTs as firmware or microcode updates. Microcode updates are the smallest target because they don't survive power outages. Attacking the TPM, BIOS, SSD, accessory ICs, or supply chain would be more useful.

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

You can look at the hash of the update file. Intel publishes their microcode data files, and you can compare them.

> in the case that you trust the vendor themselves, you have little to no way of knowing that what you have itself hasnt been modified

How is this different than any other piece of software?

Reproducible builds.

Reply on news.ycombinator.com