Excerpt:
"The result was 29 microcode operations including logic, arithmetic, load, and store commands — enough to start writing microcode code. The first microcode programs written helped with further discovery, naturally. But before long, they wrote microcode backdoors that triggered when a given calculation was performed, and stealthy trojans that exfiltrate data encrypted or “undetectably” through introducing faults programmatically into calculations. This means nearly undetectable malware that’s resident inside the CPU. (And you think the Intel Management Engine hacks made you paranoid!)"
Additionally, modern microcode updates are both encrypted and signed blobs. Granted, it's of little use if Intel/AMD are playing the role of bad actor or if the signing and decryption mechanisms are bypassed somehow; but trying to load unsigned microcode by default will result in rejection.
It's worth noting that the analysis is on old AMD microcode precisely because AMD didn't use signed microcode for a long time and so they could create custom microcode to reverse engineer what it's doing.
I think that's 'unfortunately', and I think that such updates should require the movement of a switch or jumper to be activated. Obviously the 'hands off' and 'lights out' trends in the datacenter make such a requirement a non-starter but from a security perspective it would make good sense.
I think it's good. There's not much space in the microcode patch RAM, so hiding a malicious update like you would a root kit would be extremely difficult.
"There's probably not enough space for a meaningful exploit" is never a strategy that pans out.
Hardcoded signature validation can go a long way, but of course it really needs to be bulletproof, and also take e.g. downgrade protection into consideration.
An added physical switch, while more secure, is (as the previous commenter mentioned) so impractical, that it will more likely lead to less updating of vulnerable microcode.
Updates can be stored in the BIOS flash, so if you can program this you could theoretically update the microcode. The OS can also patch the microcode during boot.
The signature/encryption is still a problem, which might be why they are using older AMD K8 and K10 processors from 2007 which didn't have this security. Still, if the keys do leak out of AMD or Intel, this is a huge security hole.
He even extracted and posted the RSA public keys used to verify the microcode. Though he later removed them, they're still available on the internet archive:
"Most update mechanisms are protected by signatures or other cryptographic primitives. However there were some indications that older CPU models (until around 2013) do not have a strong cryptographic protection and thus would accept custom updates."
