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.
AMD: Microcode Signature Verification Vulnerability
11–20 of 107 posts
Re: AMD: Microcode Signature Verification Vulnerability
#12"A test payload for Milan and Genoa CPUs that makes the RDRAND instruction return 4"... Turns out kernel RNG belt-and-suspenders was justified?
"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...
Re: AMD: Microcode Signature Verification Vulnerability
#13As 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.
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.
Re: AMD: Microcode Signature Verification Vulnerability
#14As 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.
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.
Re: AMD: Microcode Signature Verification Vulnerability
#15> 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/
Hi, I'm one of the authors and yes it was :)
Re: AMD: Microcode Signature Verification Vulnerability
#16> 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!
They only shared it now because Asus accidentally leaked it in release notes for a BIOS update Beta.
Re: AMD: Microcode Signature Verification Vulnerability
#17"A test payload for Milan and Genoa CPUs that makes the RDRAND instruction return 4"... Turns out kernel RNG belt-and-suspenders was justified?
Life imitates art:
https://imgs.xkcd.com/comics/random_number.png
Re: AMD: Microcode Signature Verification Vulnerability
#18As 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.
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)
Re: AMD: Microcode Signature Verification Vulnerability
#19Re: AMD: Microcode Signature Verification Vulnerability
#20As 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.
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,…
hugs the Q6600 don’t you ever die on me, you precious space heater.