AMD: Microcode Signature Verification Vulnerability
35 comments
·February 3, 2025wrs
rincebrain
"in theory" Linux, at least, was supposed to use rdrand's output as _one_ source of entropy, not _the only_ source.
No idea what Windows et al do for this, or if that's still true, but I believe the above description was how the argument was originally ended.
Also, tbh, if you can patch arbitrary instruction behavior, just replacing rdrand seems like far too ham fisted a tool with the level of versatility in your hands...
Tuna-Fish
Linux's rdrand use is proof against it returning bad output, but is not proof against malicious microcode. Reason for this is that the malicious microcode can examine register contents and alter the value it's returning so that mixing it into the previous source of randomness produces the desired evil value.
rincebrain
Sure, but as stated, if you don't trust the CPU at all, rdrand becomes the least of your concerns.
wahern
For organizations like the NSA, a simple hack like this is the opposite of ham-fisted, though presumably they'd try to ensure the output would pass common statistical tests. The utility in quietly breaking cryptographic protocols is presumably a major reason why it was chosen for the proof-of-concept.
rincebrain
Sure, but that was my point, was that just overriding rdrand would be much more ham-fisted than any practical attack I would expect someone to weaponize this into outside of a PoC.
dooglius
Intel's theory I believe was that it could become the only source. The argument in favor I think is the same one you are making now: anything that could hack the chip deeply enough to break rdrand is powerful enough to achieve the same goals in another way.
rincebrain
I'm sure Intel loved that idea, given that I don't think RDRAND showed up on AMD chips for 3 years after Intel launched support for it, and that would let them look much better on a number of benchmarks for that duration...
bestouff
Yes ! I wonder what's the Windows implementation of the equivalent API.
cluckindan
Run the patch and find out.
c2xlZXB5Cg1
Life imitates art: https://imgs.xkcd.com/comics/random_number.png
saagarjha
I assume the Google engineers have a sense of humor
Kab1r
Does anyone know if this is the same vulnerability that ASUS leaked in a beta BIOS?
hedora
As an end user, I wonder how my cloud provider can prove to me that they installed AMD's fix and are not simply running a malicious version of the microcode on their CPU that claims to have the fix.
wmf
In theory the PSP should probably attest the microcode but I don't know if that exists.
rincebrain
I don't think you can, necessarily, except by basically declaring bankruptcy on the old trust root on the systems and teaching everyone not to trust the old root.
As long as the vulnerability doesn't let them actually extract the secrets necessary to simulate completely arbitrary operations including with any future keys, I _think_ you can trust the new attestation chain afterward?
I've not been paid to work on this, though, and it would be pretty easy to have accidentally built it in a way where this is a world-ending event, and truly paranoid workloads in the future are going to insist on only using silicon that can't have ever been compromised by this either way.
cluckindan
hugs the Q6600 don’t you ever die on me, you precious space heater.
bornfreddy
Try to install your own patch for RDRAND and check that it is returning 4? Of course, getting 4 multiple times doesn't mean you have succeeded [0].
[0] https://duckduckgo.com/?q=dilbert+random+generator+nine+nine... (couldn't find a good link to the comic)
kyrra
For the large providers (Amazon, Google, Microsoft), they buy so many CPUs that they for issues like this, they tend to be given the fixes before they are released to the public. So I'd wager that those 3 already have patched their entire fleet.
nubinetwork
I don't know how exploitable this really is, as a lot of Linux systems load microcode at boot time... once it's been loaded, I don't think it's possible to load another one (outside of rebooting).
homebrewer
It is possible, but it's generally not a good idea.
https://wiki.archlinux.org/title/Microcode#Late_loading
https://docs.kernel.org/arch/x86/microcode.html#late-loading
although quotes from this article claim that it's fine specifically on AMD systems:
rincebrain
To my understanding, part of the reason that was a problem was that Intel wanted to killswitch feature bits like SGX, but since Linux saves the feature bit state when it inits the CPUs, and then other things might change codepaths based on that, if you then killswitch it later, boom might go the dynamite.
(I believe this example would also still break on AMD-based systems, AMD just hasn't killswitched a CPUID feature flag yet AFAIR...)
dooglius
Doesn't this give enough detail for someone to replicate easily? I'd think it would not be too hard to look at the signature and find the insecure function used.
rincebrain
There's been a bunch of scattered public research on microcode payload signatures over the years.
I would speculate that the problem is less that the hash function is weak inherently (otherwise we'd have a really complicated horizon of needing to chain microcode updates since we'd eventually want to e.g. go from MD5 to SHA1 or something), and more that the implementation has a flaw (similar to things like Nintendo using strcmp and not memcmp on their hash comparisons in the Wii, so you only had to collide the function to the first \0).
unsnap_biceps
> A test payload for Milan and Genoa CPUs that makes the RDRAND instruction return 4
I would be tickled pink if the 4 was in reference to https://xkcd.com/221/
vardump
Of course it was.
dboreham
> CPU uses an insecure hash function in the signature validation
Do we know what this "insecure hash function" is/was?
dmitrygr
$5 says CRC32
dmitrygr
> 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.
What a load of shit! Confidence is earned, it does not grow back like a weed you stepped on!
unsnap_biceps
I feel like this is a technical trust re-establishment, hence calling out specifically confidential-compute workloads
kmeisthax
They promised additional details in March - a month away. If they don't release that information in March then you can sharpen your pitchforks.
Stevvo
They only shared it now because Asus accidentally leaked it in release notes for a BIOS update Beta.
garaetjjte
Privileged code can load microcode? Duh, "vulnerability".
"A test payload for Milan and Genoa CPUs that makes the RDRAND instruction return 4"... Turns out kernel RNG belt-and-suspenders was justified?