[amluto]

Something worth noting:

CPUs have no non-volatile memory -- microcode fully resets when the power is cycled. So, in a sensible world, the impact of this bug would be limited to people temporarily compromising systems on which they already had CPL0 (kernel) access. This would break (possibly very severely and maybe even unpatchably) SEV, and maybe it would break TPM-based security if it persisted across a soft reboot, but would not do much else of consequence.

But we do not live in a sensible world. The entire UEFI and Secure Boot ecosystem is a complete dumpster fire in which the CPU, via mechanisms that are so baroque that they should have been disposed of in, well, the baroque era, enforces its own firmware security instead of delegating to an independent coprocessor. So the actual impact is that getting CPL0 access to an unpatched system [0] will allow a complete compromise of the system flash, which will almost certainly allow a permanent, irreversible compromise of that system, including persistent installation of malicious microcode that will pretend to be patched. Maybe a really nice Verified Boot (or whatever AMD calls its version) implementation would make this harder. Maybe not.

(Okay, it's not irreversible if someone physically rewrites the flash using external hardware. Good luck.)

[0] For this purpose, "unpatched" means running un-fixed microcode at the time at which CPL0 access is gained.

[mjg59]

> enforces its own firmware security instead of delegating to an independent coprocessor

That depends on how we define "independent" - AMD's firmware validation is carried out by the Platform Security Processor, which is an on-die ARM core that boots its firmware before the x86 cores come up. I don't know whether or not the microcode region of the firmware is included in the region verified by their Platform Secure Boot or not - skipping it on the basis that the CPU's going to verify it before loading it anyway seems like an "obvious" optimisation, but there's room to implement this in the way you want.

But raw write access to the flash depends on you being in SMM, and I don't know to what extent microcode can patch what SMM transitions look like. Wouldn't bet against it (and honestly would be kind of surprised if this was somehow protected), but I don't think what Google's worked out here yet gives us a solid answer.

[amluto]

By “firmware security” I meant control of writes to the SPI flash chip that controls firmware. There are other mechanisms that try to control whether the contents of the chip are trusted for various purposes at boot, and you’re probably more familiar with those than I am.

As for my guesses about the rest:

As far as I know (and I am not privy to any non-public info here), the Intel ucode patch process sure seems like it can reprogram things other than the ucode patch SRAM. There seem to be some indications that AMD’s is different.

I wouldn’t bet real money, with fairly strong odds, that this ucode compromise gives the ability to run effectively arbitrary code in SMM CPL0, without even a whole lot of difficulty other than reverse engineering enough of the CPU to understand what the uops do and which patch slots do what. I would also bet, at somewhat less aggressive odds, that ucode patches can do things that even SMM can’t, e.g. writing to locked MSRs and even issuing special extra-privileged operations like the “Debug Read” and “Debug Write” operations that Intel CPUs support in the “Red Unlock” state.

[sirdarckcat]

> But raw write access to the flash depends on you being in SMM

Look at tests/stop.sh and check the different segments (ls:, ms:, etc you can also address them like 0:[..], 1, 2, 3,... 15:[...]). One of those is probably flash. If you know how that looks like try to dump it first with a load and then check which segment and which address it is at and then write back to it.

[bri3d]

SEV attestation does delegate to the PSP, no? I think it _might_ be reasonable to attest that upgraded microcode is both present and valid using SEV, without the risk of malicious microcode blinding the attestation, but I’m not positive yet - need to think on it a bit more.

[amluto]

This probably depends on a lot of non-public info: how does the PSP validate CPU state? where does PSP firmware come from? can the PSP distinguish between a CPU state as reported by honest ucode and that state as reported by the CPU running malicious ucode?

I think that, at least on Intel, the “microcode” package includes all kinds of stuff beyond just the actual CPU microcode, and I think it’s all signed together. If AMD is like this, than an unpatched CPU can be made to load all kinds of goodies.

Also, at least in Intel (and I think also on AMD), most of the SPI flash security mechanism is controlled by SMM code. So any ranges that the CPU can write, unless locked by a mechanism outside of the control of whatever this bug compromises, can be written. This seems pretty likely to include the entire SPI chip, which includes parts controlling code that will run early after the next power cycle, which can compromise the system again.

[mjg59]

PSP firmware is in system flash, but is verified by the PSP with its own signing key. PSP firmware is loaded before x86 comes up, and as long as the SEV firmware measures itself and as long as it patches the microcode loader before allowing x86 to run (which the description of the patch claims it does) I think SEV is rescuable.

[sirdarckcat]

> This probably depends on a lot of non-public info: how does the PSP validate CPU state?

https://github.com/amd/AMD-ASPFW/blob/3ca6650dd35d878b3fcbe5...

[amluto]

That seems to be reading a memory mapped register per core. I wonder what backs that register.

[sirdarckcat]

It's just written by the CPU during a ucode update