We broke the "encryption" (more like scrambling) of the AMD K8 and K10 CPU microcode updates. We released tooling to write and apply your own microcode updates. AMD did not take any actions against us. Granted, this was a university project so we clearly were within the academic context, but we were in no way affiliated with a too big to sue company.
Any encryption/signature that can be broken in software on affordable hardware is just that: BROKEN.
What is your theory of harm? Who is harmed and how? Why should the law protect them by restricting the freedom of others?
AMD *sold* these CPUs to customers potentially running this tool on their hardware. That makes you think AMD should be entitled to restrict what the public is allowed to know about their products or does with them post sale?
Also if AMD is still in control shouldn't they be liable too? Should users get to sue AMD if an AMD CPU got compromised by malware e.g. the next side channel attack?
I might start to feel some sympathy for AMD and Intel if they voluntary paid all their customers for the effective post-sale performance downgrades inflicted on customers by mitigations required to make their CPUs fit for purpose.
Are you talking about legalities? AFAIK Hardware jailbreaking/homebrew tools are fine even in jurisdictions blighted with with DMCA unless they're specifically for circumventing DRM.
If more about morals, generally publishing vulnerability research tooling is business as usual for white hat vulnerability researchers, working at bigcorps or not, and has a long history. seems surprising to see this kind of "not cool" comment on this site.
It's not who releases it, it's who is the target that makes the difference. AMD chooses not to sue the researchers, whereas a game console maker would probably sue.
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.
Hyundai used both this same NIST AES key _and_ an OpenSSL demo RSA key together in a head unit! (search “greenluigi1” for the writeup).
Using CMAC as both the RSA hashing function and the secure boot key verification function is almost the bigger WTF from AMD, though. That’s arguably more of a design failure from the start than something to be caught.
It doesn't really fix the underlying "didn't hire a qualified cryptographer" issue. By the time a third party scanning finds it in a released firmware millions of chips will already have been produced.
Plus it would only help with that one issue, not with the millions of other ways things can go wrong. Vendors publishing their security architecture so others can convince themselves that it is in fact secure would be better, it is how TLS or WPA get enough eyeballs.
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.
You can make a new instruction (or repurpose an existing one) that accesses physical memory bypassing the page walk, which would be faster. You can also make instructions that bypasses some checks (like privilege checks) and squeeze some tiny performance. Note this would introduce security issues though, so you could only use it on trusted software.
It's interesting to think about the sorts of things we could do if we had low level control over our hardware. Unfortunately things seem consistently headed in the opposite direction.
It's not especially likely you'll be able to make things faster unless you're really strapped for fetch bandwidth. The reasoning is that most useful uops will already have instructions which directly decode to them (ie you're not going to get a faster load with ucode than if you just used a normal load instruction). In fact, given that ucode branches are (typically?) only statically predicted [1], you may well see worse performance if you need to use ucode branches with non-statically predictable directions.
CPU vendors typically gain performance when adding new instructions because they add new fancy uops. For example, x86 has AES instructions which lead to uops which (I imagine) exercise some hardware AES block. Vendors are not simply implementing AES in pure ucode as this wouldn't really gain any performance advantage over doing AES directly in software.
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.
> 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.
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.
Random off topic question: could one theoretically (with infinite time and resources) write new microcode firmware for a modern processor that turns it into an armv8+ processor?
Not on these, since the decoder is hardwired for x86-shaped instructions (prefixes, etc). Some instructions are also hardwired to produce certain uops.
As others have pointed out the short answer is no. The longer answer is still no if you value execution performance at least a little bit.
However, maybe, there is a way. Back when we were researching microcode we found a talk [1] that ran multiple ISAs in parallel on the same processor using microcode. We never figured out how this worked, our best guess is either swapping microcode from RAM as needed or branching to an emulator in x86 code. If this was a K10 cpu, which might be a bit old at the time of the talk, then there is no way you could fit an ARM interpreter into the update. You had, iirc, 32 triads of 3 operations each. Maybe, just maybe, you could fit a bytecode interpreter that then executes the actual ISA emulator. However you would need to hook every instruction, or at least trap on each instruction fetch and hook the appropriate handling routine and both sound very complicated.
If your infinite resources include manufacturing new silicon with the proper fast path and microcode decoder, then yes, but note that x86 and ARM have different memory models. Also at that point you just have a very expensive, very inefficient ARM processor.
Without more in depth knowledge here my guess would be yes, if you can fit an Emulator for armv8 into the size available for microcode. The instruction the cpu runs vs those that are emulated via microcode are already pretty extensive, running essentially an ARM Emulator on Top of it should in theory not make too much of a difference since you are essentially running an x86 Emulator on whatever the ryzen instruction set really is.
in the introduction they explain that it's not possible
"The first question everyone has about microcode updates is something like "So can I execute ARM64 code natively on my Athlon?" It's a fun idea, but now we know that a microcode patch doesn't work like that -- so the answer is no, sorry!"
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.
> We plan to provide additional details in the upcoming months on how we reverse engineered the microcode update process, which led to us identifying the validation algorithms
> 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!
nomercy400|1 year ago
Try this on any game console or drm protected device ans you are DMCAed before you know it.
rft|1 year ago
https://www.usenix.org/system/files/conference/usenixsecurit...
https://informatik.rub.de/veroeffentlichungenbkp/syssec/vero...
https://github.com/RUB-SysSec/Microcode
crest|1 year ago
What is your theory of harm? Who is harmed and how? Why should the law protect them by restricting the freedom of others?
AMD *sold* these CPUs to customers potentially running this tool on their hardware. That makes you think AMD should be entitled to restrict what the public is allowed to know about their products or does with them post sale?
Also if AMD is still in control shouldn't they be liable too? Should users get to sue AMD if an AMD CPU got compromised by malware e.g. the next side channel attack?
I might start to feel some sympathy for AMD and Intel if they voluntary paid all their customers for the effective post-sale performance downgrades inflicted on customers by mitigations required to make their CPUs fit for purpose.
fulafel|1 year ago
If more about morals, generally publishing vulnerability research tooling is business as usual for white hat vulnerability researchers, working at bigcorps or not, and has a long history. seems surprising to see this kind of "not cool" comment on this site.
Beretta_Vexee|1 year ago
‘In the courts, you will be deemed either innocent or guilty, according to your wealth or poverty.’
BSDobelix|1 year ago
mrb|1 year ago
Fokamul|1 year ago
Same with apps, aka everything is opensource if you know RE ;-)
perching_aix|1 year ago
dzdt|1 year ago
nyanpasu64|1 year ago
throwaway984393|1 year ago
transpute|1 year ago
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.
bri3d|1 year ago
Using CMAC as both the RSA hashing function and the secure boot key verification function is almost the bigger WTF from AMD, though. That’s arguably more of a design failure from the start than something to be caught.
the8472|1 year ago
Plus it would only help with that one issue, not with the millions of other ways things can go wrong. Vendors publishing their security architecture so others can convince themselves that it is in fact secure would be better, it is how TLS or WPA get enough eyeballs.
BonusPlay|1 year ago
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...
sirdarckcat|1 year ago
dtgriscom|1 year ago
sirdarckcat|1 year ago
fc417fc802|1 year ago
It's interesting to think about the sorts of things we could do if we had low level control over our hardware. Unfortunately things seem consistently headed in the opposite direction.
sweetjuly|1 year ago
CPU vendors typically gain performance when adding new instructions because they add new fancy uops. For example, x86 has AES instructions which lead to uops which (I imagine) exercise some hardware AES block. Vendors are not simply implementing AES in pure ucode as this wouldn't really gain any performance advantage over doing AES directly in software.
[1] https://arxiv.org/html/2501.12890v1
nomercy400|1 year ago
saagarjha|1 year ago
amluto|1 year ago
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|1 year ago
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.
bri3d|1 year ago
nullc|1 year ago
junon|1 year ago
dmitrygr|1 year ago
rft|1 year ago
However, maybe, there is a way. Back when we were researching microcode we found a talk [1] that ran multiple ISAs in parallel on the same processor using microcode. We never figured out how this worked, our best guess is either swapping microcode from RAM as needed or branching to an emulator in x86 code. If this was a K10 cpu, which might be a bit old at the time of the talk, then there is no way you could fit an ARM interpreter into the update. You had, iirc, 32 triads of 3 operations each. Maybe, just maybe, you could fit a bytecode interpreter that then executes the actual ISA emulator. However you would need to hook every instruction, or at least trap on each instruction fetch and hook the appropriate handling routine and both sound very complicated.
If your infinite resources include manufacturing new silicon with the proper fast path and microcode decoder, then yes, but note that x86 and ARM have different memory models. Also at that point you just have a very expensive, very inefficient ARM processor.
[1] https://troopers.de/events/troopers16/655_the_chimaera_proce...
IlikeKitties|1 year ago
mtoner23|1 year ago
"The first question everyone has about microcode updates is something like "So can I execute ARM64 code natively on my Athlon?" It's a fun idea, but now we know that a microcode patch doesn't work like that -- so the answer is no, sorry!"
porridgeraisin|1 year ago
mkj|1 year ago
sanxiyn|1 year ago
> We plan to provide additional details in the upcoming months on how we reverse engineered the microcode update process, which led to us identifying the validation algorithms
p1mrx|1 year ago
How does that work? Did someone figure out AMD's private keys?
yuriks|1 year ago
> 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!
AHTERIX5000|1 year ago
Julesman|1 year ago