4 ms·

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

by hedora 2y ago

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.

kyrra 2y ago
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.
rincebrain 2y ago
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 2y ago
  hugs the Q6600 don’t you ever die on me, you precious space heater.
bornfreddy 2y ago
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&t=fpas&iar=images&iax=images&ia=images https://duckduckgo.com/?q=dilbert+random+generator+nine+nine... (couldn't find a good link to the comic)
- tedunangst 2y ago
  The exploit doesn't work in a VM.
wmf 2y ago
In theory the PSP should probably attest the microcode but I don't know if that exists.
- bpye 2y ago
  SEV-SNP VMs can obtain an attestation report [0]. [0] - https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56860.pdf https://www.amd.com/content/dam/amd/en/documents/epyc-techni...
  - anon2025b 2y ago
    What does it actually attest though? The running microcode's revision ID? Or the running microcode's ROM version plus loaded patch lines plus active match registers plus whatever settings were adjusted in config registers during the act of loading? That is, attest the actual and complete config that is running, or some pointless subset that instills a false sense of security? It would be good for AMD (and Intel etc.) to provide better details here.
alberth 2y ago
Don't microcode updates require a restart as well.
- monocasa 2y ago
  They do not.
- formerly_proven 2y ago
  Microcode updates aren't persistent, they're loaded into on-CPU-SRAM by firmware and/or kernel.
bri3d 2y ago
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-technical-docs/specifications/57230.pdf 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.
- kccqzy 2y ago
  While I agree with you, from experience most people and most workloads definitely aren't using SEV-SNP. The hypervisor and the cloud provider are always assumed to be honest. I personally evaluated this technology a few years ago, and even just moving a small part of our team's workload to SEV-SNP faced so much resistance from the VP level. I'm not sure if that's more of a problem with bureaucracy at my old employer or a general problem.
  - bri3d 2y ago
    Oh, 100%. My point was just: if you're worried that you can't audit your cloud provider's microcode patch level because you aren't using SEV-SNP, you have a threat model where their microcode patch level is not particularly relevant to you to begin with.
RachelF 2y ago
Will the OS fix the microcode, or will a BIOS flash be required?

by hedora 2y ago

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.

kyrra 2y ago

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.

rincebrain 2y ago

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 2y ago
hugs the Q6600 don’t you ever die on me, you precious space heater.

bornfreddy 2y ago

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&t=fpas&iar=images&iax=images&ia=images https://duckduckgo.com/?q=dilbert+random+generator+nine+nine... (couldn't find a good link to the comic)

tedunangst 2y ago
The exploit doesn't work in a VM.

wmf 2y ago

In theory the PSP should probably attest the microcode but I don't know if that exists.

bpye 2y ago
SEV-SNP VMs can obtain an attestation report [0]. [0] - https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56860.pdf https://www.amd.com/content/dam/amd/en/documents/epyc-techni...
- anon2025b 2y ago
  What does it actually attest though? The running microcode's revision ID? Or the running microcode's ROM version plus loaded patch lines plus active match registers plus whatever settings were adjusted in config registers during the act of loading? That is, attest the actual and complete config that is running, or some pointless subset that instills a false sense of security? It would be good for AMD (and Intel etc.) to provide better details here.

alberth 2y ago

Don't microcode updates require a restart as well.

monocasa 2y ago
They do not.
formerly_proven 2y ago
Microcode updates aren't persistent, they're loaded into on-CPU-SRAM by firmware and/or kernel.

bri3d 2y ago

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-technical-docs/specifications/57230.pdf 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.

kccqzy 2y ago
While I agree with you, from experience most people and most workloads definitely aren't using SEV-SNP. The hypervisor and the cloud provider are always assumed to be honest. I personally evaluated this technology a few years ago, and even just moving a small part of our team's workload to SEV-SNP faced so much resistance from the VP level. I'm not sure if that's more of a problem with bureaucracy at my old employer or a general problem.
- bri3d 2y ago
  Oh, 100%. My point was just: if you're worried that you can't audit your cloud provider's microcode patch level because you aren't using SEV-SNP, you have a threat model where their microcode patch level is not particularly relevant to you to begin with.

RachelF 2y ago

Will the OS fix the microcode, or will a BIOS flash be required?