3 ms·

The big question is whether this can break out of KVM and whether it can be microrode patched / patched in any other way. And whether it's really real in the f

The big question is whether this can break out of KVM and whether it can be microrode patched / patched in any other way. And whether it's really real in the first place.

summa_tech 2mo ago
One hopes that a hypervisor would not expose hardware control registers directly in the first place, except ones deliberately designed for virtualization support. Otherwise, the guest is running effectively at the same privilege level as the hypervisor (that's useful sometimes, but probably not intended in most applications).
- devttyeu 2mo ago
  Yeah, just started looking at this with my team (we run a cloud with VM instance offering on AMD so this very much caught our eye) So far seems this is about right: 1. You need platform register access, so seems can't KVM-escape with just this 2. Big question is what about breaking Confidential SEV-SNP guests from the host?
  - devttyeu 2mo ago
    Ok, on 2. and in general this exploit only works on pre-Zen AMD platforms as the repo states in not-so-clear terms. Zen changed DTC (DRAM Controller) to UMC (Unified Memory Controller), UMC is programmed at boot, and one would hope they figured that locking access to it makes sense when they were adding confidential compute support; Not clear though because there is no public documentation on it, so best we can hope for is some statement from AMD/3rd party researcher saying "this won't work on Zen because X/Y/Z"
  - bri3d 2mo ago
    With respect to 2), I don't think this should work architecturally even if the DRAM controller has knobs which can be accessed, because the guest's RAM should be encrypted with keys that can't be recovered in this way. It's definitely a good research topic because there are a lot of moving pieces and having this kind of primitive might weaken one of them in a useful way, but at least at the top level, you couldn't just swap one guest's DRAM bank with another and get their confidential memory contents back this way.
quotemstr 2mo ago
This hack is 99% giving people the control over their own computers they should already have had. Guy is a Robin Hood.
- MSFT_Edging 2mo ago
  When Chris Domas left Battelle for Intel years back, shortly after hardware-fuzzing a bank of thin-clients to discover undocumented x86 instructions, I was convinced Intel was basically keeping him on the payroll to shut him up.
vsrinivas 2mo ago
1) Don't give your guests access to the DCT control registers. 2) On 15h - no obvious way. I don't know the other families. 3) Yes -- this can be verified easily. Pick up the AMD 15h BKDG, look up BankSwizzleMode. It's documented. The one oversight is that this bit is not under the Dram Controller's lock bit.

The big question is whether this can break out of KVM and whether it can be microrode patched / patched in any other way. And whether it's really real in the first place.

summa_tech 2mo ago

One hopes that a hypervisor would not expose hardware control registers directly in the first place, except ones deliberately designed for virtualization support. Otherwise, the guest is running effectively at the same privilege level as the hypervisor (that's useful sometimes, but probably not intended in most applications).

devttyeu 2mo ago
Yeah, just started looking at this with my team (we run a cloud with VM instance offering on AMD so this very much caught our eye) So far seems this is about right: 1. You need platform register access, so seems can't KVM-escape with just this 2. Big question is what about breaking Confidential SEV-SNP guests from the host?
- devttyeu 2mo ago
  Ok, on 2. and in general this exploit only works on pre-Zen AMD platforms as the repo states in not-so-clear terms. Zen changed DTC (DRAM Controller) to UMC (Unified Memory Controller), UMC is programmed at boot, and one would hope they figured that locking access to it makes sense when they were adding confidential compute support; Not clear though because there is no public documentation on it, so best we can hope for is some statement from AMD/3rd party researcher saying "this won't work on Zen because X/Y/Z"
- bri3d 2mo ago
  With respect to 2), I don't think this should work architecturally even if the DRAM controller has knobs which can be accessed, because the guest's RAM should be encrypted with keys that can't be recovered in this way. It's definitely a good research topic because there are a lot of moving pieces and having this kind of primitive might weaken one of them in a useful way, but at least at the top level, you couldn't just swap one guest's DRAM bank with another and get their confidential memory contents back this way.

quotemstr 2mo ago

This hack is 99% giving people the control over their own computers they should already have had. Guy is a Robin Hood.

MSFT_Edging 2mo ago
When Chris Domas left Battelle for Intel years back, shortly after hardware-fuzzing a bank of thin-clients to discover undocumented x86 instructions, I was convinced Intel was basically keeping him on the payroll to shut him up.

vsrinivas 2mo ago

1) Don't give your guests access to the DCT control registers. 2) On 15h - no obvious way. I don't know the other families. 3) Yes -- this can be verified easily. Pick up the AMD 15h BKDG, look up BankSwizzleMode. It's documented. The one oversight is that this bit is not under the Dram Controller's lock bit.