Message-ID: <ecf005b1-ddb9-da4c-4526-28df4806426c@linux.microsoft.com>
Date:   Thu, 23 Mar 2023 15:46:22 +0100
From:   Jeremi Piotrowski <jpiotrowski@...ux.microsoft.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     linux-kernel@...r.kernel.org,
        Brijesh Singh <brijesh.singh@....com>,
        Tom Lendacky <thomas.lendacky@....com>,
        "Kalra, Ashish" <ashish.kalra@....com>,
        linux-crypto@...r.kernel.org,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>, linux-acpi@...r.kernel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org
Subject: Re: [PATCH v3 0/8] Support ACPI PSP on Hyper-V

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.

Powered by blists - more mailing lists