Google: How to make any AMD Zen CPU always generate 4 as a random number
- Reference: 1738711846
- News link: https://www.theregister.co.uk/2025/02/04/google_amd_microcode/
- Source link:
And this ability to change the microcode not only allows Google and others to customize the operation of their AMD chips, for good and non-good reasons, but it also smashes the Epyc maker's secure encrypted virtualization and root-of-trust security features.
Background
Microcode is a special block of programs typically loaded into a processor during system startup that defines the way the chip works. By providing microcode to users, AMD can add some features, fix certain issues, and extend some functionality without having to redesign and reissue the physical silicon. It is a patch that updates your chip – Intel has similar – and crucially only AMD is supposed to be able to produce working microcode updates for its products.
AMD bakes a cryptographic security mechanism into its processors that checks a microcode update truly came from AMD before accepting it. The format of the microcode is also not documented publicly and is highly proprietary and protected. All of this is to stop someone from coming up with their own viable microcode and making an AMD processor do things it shouldn't or in a non-standard way.
Well, the boffins at Google have discovered a way to craft their own microcode that is accepted by AMD processors and successfully changes the silicon's operation. They say their technique works on all Zen-based AMD chips – all Ryzen and Epyc parts, basically.
How (not very) random
To back up these claims, the Googlers this week released [1]initial details of their findings, and a proof-of-concept microcode update for Milan-family Epyc server chips and Phoenix-family Ryzen 9 desktop processors. This [2]demo microcode forces a chip's read random ( [3]RDRAND ) instruction to always output the value 4 rather than an actual random number, likely a reference to [4]XKCD .
The Googlers carefully neutered their proof-of-concept, we note. The altered RDRAND instruction always clears the CPU core's carry flag to zero, signaling to applications the value isn't valid. Thus if some miscreant were to start distributing the patch, well-written apps and libraries should refuse to use the static number on hobbled processors. This is important because RDRAND is used by software to generate random values for strong secure encryption and other cryptography; a value of always 4 will silently wreck that data protection.
[5]
The implications of this are fairly large. It demonstrates how software instructions can be altered or extended by unofficial microcode patches, that Google and potentially others can craft such patches, and that these patches could be used for good – improving CPU operations – and bad, such as backdooring systems or weakening security. There has been prior research into AMD's microcode format (eg, [6]here and [7]here ) though Google's work covers AMD's latest parts down to those shipping in 2017.
This vulnerability could be used by an adversary to compromise confidential computing workloads
Crucially, you need to kernel-level, ring-0 access on a system to load the microcode, so this can only be used once you have sufficient privileges. This makes this technique more useful for those customizing their own systems, or for privileged malware that really wants to deeply compromise an infected computer.
But consider a scenario where you're running a virtual machine on a remote host that you may not fully trust, so you rely on AMD's secure encrypted virtualization to [8]shield your VM from the host ; now the host can use Google's approach to load microcode that undermines or blows away that security.
The problem
From what we can tell, the Google team was able to produce microcode updates that appear to be digitally signed by AMD, or signed in a way the processor will expect, while containing code that isn't from AMD. This is achieved by exploiting a weak hash algorithm in the chip, we're told.
"We have demonstrated the ability to craft arbitrary malicious microcode patches on Zen 1 through Zen 4 CPUs," the Google Security Team explained in their advisory on Monday.
[9]
[10]
"The vulnerability is that the CPU uses an insecure hash function in the signature validation for microcode updates.
"This vulnerability could be used by an adversary to compromise confidential computing workloads protected by the newest version of AMD Secure Encrypted Virtualization, SEV-SNP or to compromise Dynamic Root of Trust Measurement."
Fixing it
AMD and Google both consider this loading of unofficial CPU patches a security vulnerability, which we got [11]a glimpse of in January when Asus jumped the gun by accidentally disclosing a microcode-related security fix was coming.
The flaw, listed as CVE-2024-56161 with a CVSS score of 7.2 out of 10, was discovered and reported to AMD in September, and a fix was devised by December. That remediation is being rolled out in the form of, ironically enough, an official microcode update via system manufacturers from AMD. So far it appears [12]AMD has issued patches for datacenter-class and embedded processors, and nothing yet officially for its personal computing chips.
[13]
That said, the Asus leak from earlier was a beta BIOS update for AMD-powered gaming motherboards that fixed this microcode security issue, so updates for Ryzen and Threadripper components may be on their way. We're seeking clarification.
AMD stressed CVE-2024-56161 is exploitable only by someone with host admin access. "Once that level of access is achieved, almost anything is possible," a spokesperson told The Register .
We also note the hole cannot be exploited by an admin in a virtualized guest; you need kernel-level ring-0 access on the host, outside any virtual machines running.
[14]Asus lets processor security fix slip out early, AMD confirms patch in progress
[15]Spectre flaws continue to haunt Intel and AMD as researchers find fresh attack method
[16]Intel, AMD engineers rush to save Linux 6.13 after dodgy Microsoft code change
[17]AMD sharpens silicon swords to take on chip and AI rivals
"AMD has made available a mitigation for this issue which requires updating microcode on all impacted platforms to help prevent an attacker from loading malicious microcode," the chip designer explained.
"Additionally, an SEV firmware update is required for some platforms to support SEV-SNP attestation. Updating the system BIOS image and rebooting the platform will enable attestation of the mitigation. A confidential guest can verify the mitigation has been enabled on the target platform through the SEV-SNP attestation report."
[18]
Epyc processors going all the way back to 2017 are affected, at least. More details are due to be released by Google next month.
"Due to the deep supply chain, sequence, and coordination required to fix this issue, we will not be sharing full details at this time in order to give users time to re-establish trust on their confidential-compute workloads," the G-team wrote. "We will share additional details and tools on March 5, 2025."
AMD thanked Googlers Josh Eads, Kristoffer Janke, Eduardo 'Vela' Nava, Tavis Ormandy, and Matteo Rizzo for their help in identifying and fixing the issue. ®
Get our [19]Tech Resources
[1] https://github.com/google/security-research/security/advisories/GHSA-4xq7-4mgh-gp6w
[2] https://github.com/google/security-research/tree/master/pocs/cpus/entrysign
[3] https://www.felixcloutier.com/x86/rdrand
[4] https://xkcd.com/221/
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Z6LwefUkJZjo34YU3DqRDAAAAVc&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[6] https://github.com/RUB-SysSec/Microcode/tree/master/Usenix17
[7] https://media.ccc.de/v/35c3-9614-inside_the_amd_microcode_rom
[8] https://www.amd.com/en/developer/sev.html
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z6LwefUkJZjo34YU3DqRDAAAAVc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z6LwefUkJZjo34YU3DqRDAAAAVc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[11] https://www.theregister.com/2025/01/23/asus_amd_processor_fix/
[12] https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3019.html
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Z6LwefUkJZjo34YU3DqRDAAAAVc&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[14] https://www.theregister.com/2025/01/23/asus_amd_processor_fix/
[15] https://www.theregister.com/2024/10/18/spectre_problems_continue_amd_intel/
[16] https://www.theregister.com/2025/01/14/microsoft_linux_change_pulled/
[17] https://www.theregister.com/2024/09/12/amd_conference_comments/
[18] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Z6LwefUkJZjo34YU3DqRDAAAAVc&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[19] https://whitepapers.theregister.com/
Zero trust
Be as that may, SEV is a selling point for AMD and Intel (or the equiv thereof). It's for paranoid-leaning corporations that don't trust or can't trust their hypervisor / cloud provider's internal security.
Orgs like banks, governments, and healthcare providers that want to put sensitive info on other people's computers, basically.
C.
'likely a reference to XKCD'
I like to think they flipped a coin to decide between the xkcd reference and the Dilbert reference (nine nine nine nine..)
(props to those who worked on this by the way, looking forward to 5th March to geek out on the microcode details a bit)
The Answer?
I'm truly surprised they didn't make the return value 42.
"An insecure hash"
Doubtless they used MD5, because really, it's secure enough for basically everything.
However, it's probably an offer to the US TLA's -- something that's "secure" unless you have Google-level resources to reverse an MD5 HMAC. It needs a signing key with the data, hmac generated. That, and the microcode documentation so that the US can make these chips do whatever they deign. Because there's only *one* key to find (like government backdoor'd encryption, *again*), it makes a prime target for entities with resources -- and, as demonstrated, backdoors will be unlocked by others. Now that someone other than the TLA has shown its vulnerability, "Oops, hah, hah, that was a *total* oversight, lets get that fixed, then. Here ya go."
This is not something that anyone but nations and corporations the size of Google can achieve -- and how much did Google spend on this, anyway? I guess about $50 000 to crack an md5 hash these days, right? for a proof-of-concept?
The fix is obvious: code the microcode to check for a *second* signature, of sha1 or sha256 (I wonder which -- if it's not at least sha256, then they're again giving concessions to the TLA's). Then the newer microcode is included in the BIOS of patched motherboards (so that it can't be worked around), and loaded (first!!?) for anything else -- preventing later loading of an attack microcode. All microcodes will still have to be signed (first) with the MD5 hmac, so that *any* cpu (even older ones) will accept the real microcode patched with a stronger hash, but then the same microcode will reverify itself (because theater), and verify the stronger hash of any later-loaded microcode (forward-security).
In the Olden Days, Microcode
... could be written and loaded by ordinary users; it wasn't special secret sauce. Some uni group wrote a set of microcode for a DEC PDP 11 which turned it into a Pick machine (the Pick instruction set was optimised for datsbase operations).
Epyc fail
if trust is a true issue
Don't use someone else's computer to run your VMs on regardless. There will always be security issues around that. Most people probably don't care. But I would never put much stock in such features myself.
I for one am not a fan of all this nrw fangled signing and encryption stuff in thr name of security to take control away from the person who owns or operates the equipment.