On 3/22/2023 7:15 PM, Borislav Petkov wrote: > On Wed, Mar 22, 2023 at 06:33:37PM +0100, Jeremi Piotrowski wrote: >> What this does is it allows a normal (non-SNP) VM to host confidential (SNP) >> VMs. I say "normal" but not every VM is going to be able to do this, it needs > > If you say "non-SNP" VM then this sounds like purely for development. > Because I cannot see how you're going to give the confidentiality > guarantee to the SNP guests if the lower level is unencrypted, non-SNP > and so on... Not at all. Just to be clear: this lights up all the same bits of SNP as it does on bare-metal, none of it is emulated away. On bare-metal the hypervisor underneath the SNP guest is unencrypted as well. Here the stack is: L0 (Hyper-V), L1 (KVM) and L2 (SNP guest). Starting an SNP guest is the same and involves sending commands to the PSP: * SNP_GCTX_CREATE * SNP_LAUNCH_START * SNP_LAUNCH_UPDATE * SNP_LAUNCH_FINISH Pages need to be assigned to a specific L2 SNP guest in the system-wide "reverse map table", at which point neither L0 nor L1 hypervisor can touch them. Every L2 SNP guests memory is encrypted with a different key, and the SNP guest can fetch a hardware signed attestation report from the PSP that includes a hash of all the pages that were loaded (and encrypted) into the VM address space at the time the VM was launched. The communication channel between L2 guest and PSP is secured using keys that the PSP injects into the SNP guest's address space at launch time. Honestly, I find it pretty cool that you can stuff a whole extra hypervisor underneath the SNP guest, and the hardware will still ensure and attest to the fact that neither hypervisor is able to compromise the integrity and confidentiality of the VM enclave. And you can verify this claim independently. > >> to be running on AMD hardware and configured to have access to >> VirtualizationExtensions, a "HardwareIsolation" capability, and given a number >> of "hardware isolated guests" that it is allowed to spawn. In practice this >> will result in the VM seeing a PSP device, SEV-SNP related CPUID >> leafs, and have access to additional memory management instructions >> (rmpadjust/psmash). This allows the rest of the of KVM-SNP support to >> work. > > So why don't you emulate the PSP in KVM instead of doing some BIOS hack? > And multiplex the access to it between all the parties needing it? > Not sure I follow you here. The quoted paragraph talks about what the L1 VM (KVM) sees. The L1 VM needs to issue PSP commands to bring up an L2 SNP guest, and later the L1 VM relays SNP guest commands to the PSP. The PSP commands are multiplexed to the physical PSP by the L0 hypervisor (Hyper-V). So Hyper-V exposes a PSP to the L1 VM because it is needed and it is compatible with the existing Linux driver that handles the PSP. The way it is exposed (ACPI table) follows how it was specified by AMD.
