Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zentool – AMD Zen Microcode Manipulation Utility

github.com

Post reply on HN
Print view View original

21–30 of 69 posts

Re: Zentool – AMD Zen Microcode Manipulation Utility

#21

Post by mjg59 »

amluto wrote: post #18

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,…

> 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.

Re: Zentool – AMD Zen Microcode Manipulation Utility

#22

Post by mjg59 »

amluto wrote: post #20
bri3d wrote: post #19

Earlier quoted context omitted.

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.

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. I…

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.

Re: Zentool – AMD Zen Microcode Manipulation Utility

#23

Post by amluto »

mjg59 wrote: post #21
amluto wrote: post #18

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,…

> 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 B…

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.

Re: Zentool – AMD Zen Microcode Manipulation Utility

#25

Post by RachelF »

taviso wrote: post #5
yuriks wrote: post #4

Earlier quoted context omitted.

The intro document mentions > Here's the thing - the big vendors encrypt and sign their updates so that you cannot run your own microcode. A big discovery recently means that the authentication scheme is a lot weaker than intended, and you can now effectively "jailbreak" your CPU! But there's no further details. I'd love to know about the specifics too!

They accidentally used the example key from AES-CMAC RFC, the full details are in the accompanying blog post: https://bughunters.google.com/blog/5424842357473280/zen-and-...

Yikes! One would have expected a little more code review or a design review from a hardware manufacturer, especially of security system. A system that people have been worried about since the Pentium FDIV bug.

I guess this one just slipped through the cracks?

Re: Zentool – AMD Zen Microcode Manipulation Utility

#26

Post by wtallis »

__turbobrew__ wrote: post #15
bpye wrote: post #12

Earlier quoted context omitted.

> The fix released by AMD modifies the microcode validation routine to use a custom secure hash function. This is paired with an AMD Secure Processor update which ensures the patch validation routine is updated before the x86 cores can attempt to install a tampered microcode patch.

What if your cpu microcode already has malware which injects itself into the microcode update? https://dl.acm.org/doi/10.1145/358198.358210

CPUs don't have non-volatile storage for microcode updates; it gets uploaded on boot from a copy stored alongside the other firmware in a flash chip on the motherboard, or optionally later in the boot process when an OS loads a microcode update from some other storage device. So a malicious microcode update that's trying to persist itself doesn't have to monitor for attempts to update CPU microcode, it has to detect attempts to install a BIOS update that includes a microcode update, find and poison the microcode update embedded within that BIOS update, and subvert any attempt to checksum the flash contents before rebooting. Fitting an attack that complex into CPU microcode patches that are on the order of a kilobyte is extremely implausible.

Re: Zentool – AMD Zen Microcode Manipulation Utility

#27

Post by RachelF »

nyanpasu64 wrote: post #11
dzdt wrote: post #3

The blog post that explains the exploit and how this whole thing works is at https://bughunters.google.com/blog/5424842357473280/zen-and-...

Is the mitigation something that has to be installed on every system boot and only protects against microcode exploits later on that boot?

I would guess it is a BIOS patch, just like the microcode normally is.

So it probably needs to be installed at every system boot.

Perhaps someone more knowledgeable can correct my guesses?

Re: Zentool – AMD Zen Microcode Manipulation Utility

#30

Post by sirdarckcat »

BonusPlay wrote: post #7

Both AMD and Google note, that Zen[1-4] are affected, but what changed about Zen5? According to the timeline, it released before Google notified AMD [1]. Is it using different keys, but same scheme (and could possibly be broken via side-channels as noted in the article)? Or perhaps AMD notices something and changed up the microcode? Some clarification on that part would be nice. [1] https://github.com/google/security…

We were not able to demonstrate that Zen5 is affected. If we end up doing so, we may release a new advisory or something.
Post reply on HN