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.
Don't microcode updates require a restart as well.
AMD: Microcode Signature Verification Vulnerability
41–50 of 107 posts
Re: AMD: Microcode Signature Verification Vulnerability
#42"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 han…
Windows collects hardware device entropy and mixes it into the pool.
It also persists the pool across reboots so it doesn't start empty.
Re: AMD: Microcode Signature Verification Vulnerability
#43Does anyone know if this is the same vulnerability that ASUS leaked in a beta BIOS?
To the very best of my knowledge, yes, it is.
Re: AMD: Microcode Signature Verification Vulnerability
#44As 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.
It's in the CVE: "AMD SEV-SNP users can verify the fix by confirming TCB values for SNP in their attestation reports."
You can read about how this works here: https://www.amd.com/content/dam/amd/en/documents/epyc-techni...
If you aren't using SEV-SNP / attested compute, you have bigger fish to fry anyway since you have no actual trust in your hypervisor.
Re: AMD: Microcode Signature Verification Vulnerability
#45How do they know the internal microcode structure of instructions or even format?
Re: AMD: Microcode Signature Verification Vulnerability
#46How do they know the internal microcode structure of instructions or even format?
Some people are very good at this, e.g. https://app.media.ccc.de/v/35c3-9614-inside_the_amd_microcod...
Re: AMD: Microcode Signature Verification Vulnerability
#47Does anyone know if this is the same vulnerability that ASUS leaked in a beta BIOS?
[deleted]
Re: AMD: Microcode Signature Verification Vulnerability
#48Earlier quoted context omitted.
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.
Sure, but as stated, if you don't trust the CPU at all, rdrand becomes the least of your concerns.
The thing is, all the other ways you can compromise the kernel from microcode are at least theoretically detectable. A security researcher could study how the cpu operates and find the exploit. If RDRAND is surreptitiously replacing all your random numbers with AES of the current time, you cannot find that out from observing behavior.
I agree that worrying about RDRAND shouldn't probably be on the top of anyone's priorities, but there is some cause to at least use it defensively, for example using it to pre-fill buffers with random values in a different context, so that subversion would in the very least require memory references, instead of running RDRAND in the context of your RNG.
Re: AMD: Microcode Signature Verification Vulnerability
#49Re: AMD: Microcode Signature Verification Vulnerability
#50"A test payload for Milan and Genoa CPUs that makes the RDRAND instruction return 4"... Turns out kernel RNG belt-and-suspenders was justified?
I wouldn't focus so much on the rdrand part. That's more a proof that they have crafted a custom microcode than trying to say that rdrand is broken.