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.
What's the need for supplying all that other gunk like destination ID,
interrupt vector and so on?
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
