Google: How to make any AMD Zen CPU always generate 4 as a random number

Googlers have not only figured out how to break AMD's security – allowing them to load unofficial microcode into its processors to modify the silicon's behavior as they wish – but also demonstrated this by producing a microcode patch that makes the chips always output 4 when asked for a random number.

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 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 demo microcode forces a chip's read random (RDRAND) instruction to always output the value 4 rather than an actual random number, likely a reference to 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.

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, here and 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 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.

"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 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 AMD has issued patches for datacenter-class and embedded processors, and nothing yet officially for its personal computing chips.

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.

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

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