This package provides a suite of tools for analyzing, manipulating and
generating microcode patches for AMD Zen processors.
The command zentool is a frontend to various utilities. There is also a
mcas, a simple assembler and mcop a simple disassembler.
Note: We also have an introduction to microcoding, and
a programming reference.
The general format of a command is:
$ zentool [GLOBALOPTIONS] CMD [COMANDOPTIONS] [FILE...]
Type zentool help to see a list of available commands.
You can examine the header of a microcode update file using the print
command:
$ zentool print data/cpu00860F01_ver0860010F_2024-11-18_785D74AB.bin
Date: 11182024 (Mon Nov 18 2024)
Revision: 0860010f
Format: 8004
Patchlen: 00
Init: 00
Checksum: 00000000
NorthBridge: 0000:0000
SouthBridge: 0000:0000
Cpuid: 00008601 AMD Ryzen (Grey Hawk, Renoir)
Stepping 1
Model: 0
Extmodel: 6
Extfam: 8
BiosRev: 00
Flags: 00
Reserved: 0000
Signature: 9c... (use --verbose to see) (GOOD)
Modulus: c7... (use --verbose to see)
Check: 5a... (use --verbose to see) (GOOD)
Autorun: false
Encrypted: false
Revision: 0860010f (Signed)
Let’s modify that revision number using the edit command, and save the result
to modified.bin:
$ zentool --output modified.bin edit --hdr-revision 0x8600141 data/cpu00860F01_ver0860010F_2024-11-18_785D74AB.bin
$ zentool print modified.bin | grep -m1 ^Revision:
Revision: 08600141
That worked, but now the signature will be incorrect:
$ zentool verify modified.bin
modified.bin: BAD
You can use the resign command to compensate for the changes you made:
$ zentool resign modified.bin
$ zentool verify modified.bin
modified.bin: GOOD
Now you can apply that update to your processor with the load command, this
requires root privileges:
$ sudo zentool load --cpu=2 modified.bin
Now we can verify that worked by querying the microcode revision:
$ sudo rdmsr -c -a 0x8b
0x8608103
0x8608103
0x8608141 <---
0x8608103
0x8608103
0x8608103
0x8608103
0x8608103
Th
9 Comments
p1mrx
> You can use the `resign` command to compensate for the changes you made:
How does that work? Did someone figure out AMD's private keys?
dzdt
The blog post that explains the exploit and how this whole thing works is at https://bughunters.google.com/blog/5424842357473280/zen-and-…
BonusPlay
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-research/security/advisor…
mkj
Was the microcode signing scheme documented by AMD, or did the researchers have to reverse engineer it somehow? I couldn't see a mention in the blog post.
transpute
This is not the first case of accidental reuse of example keys in firmware signing, https://kb.cert.org/vuls/id/455367
Would it be useful to have a public list of all example keys that could be accidentally used, which could be CI/CD tested on all publicly released firmware and microcode updates?
If there was a public test suite, Linux fwupd and Windows Update could use it for binary screening before new firmware updates are accepted for distribution to endpoints.
dtgriscom
Are there any examples of using this for non-nefarious reasons? For instance, could I add new instructions that made some specific calculation faster?
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.
nomercy400
Wow, so providing a tool for bypassing the protection mechanism of a device (cpu) is accepted when it comes from google?
Try this on any game console or drm protected device ans you are DMCAed before you know it.
nomercy400
Doesn't changing how your cpu's microcode works mean you can bypass or leak all kinds of security measures and secrets?