On 3/23/2023 4:23 PM, Borislav Petkov wrote: > On Thu, Mar 23, 2023 at 03:46:22PM +0100, Jeremi Piotrowski wrote: >> 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). > > Yeah, I talked to folks after sending that email yesterday. Apparently > it is ok to do that without compromising SNP guest security but I, in my > eternal paranoia, somehow don't have the warm and fuzzy feeling about > it. > >> ... 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. > > Yeah, all the levels below L2 are required to do it set up env properly > so that L2 SNP guests can run. > >> Honestly, I find it pretty cool that you can stuff a whole extra hypervisor >> underneath the SNP guest, > > Whatever floats your boat. :-) > > As long as it doesn't mess up my interrupt setup code with crazy hacks. > >> 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. > > No no, it was specified by Microsoft architects. > > So, that same interface to the PSP can be done by L0 emulating > a standard ACPI device for the KVM L1 HV and then L1 can use the normal > ACPI interrupt #9. > That same interface is exposed by physical hardware+firmware to the underlying Hyper-V. So it wasn't a matter of Microsoft architects coming up with a guest-host interface but rather exposing the virtual hardware in the same way as on a physical server. > What's the need for supplying all that other gunk like destination ID, > interrupt vector and so on? I'm not sure what drove the design decisions that led to the interface looking the way it does. What I can do is put in the work to map it into kernel constructs in the most native way possible and in a way that doesn't look or feel like a crazy hack. > > Thx. >
