Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <105d019c-2249-5dfd-e032-95944ea6dc8c@linux.microsoft.com>
Date:   Thu, 23 Mar 2023 17:11:26 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.9.0
Subject: Re: [PATCH v3 0/8] Support ACPI PSP on Hyper-V
Content-Language: en-US
To:     Borislav Petkov <bp@alien8.de>
Cc:     linux-kernel@vger.kernel.org,
        Brijesh Singh <brijesh.singh@amd.com>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        "Kalra, Ashish" <ashish.kalra@amd.com>,
        linux-crypto@vger.kernel.org,
        "Rafael J. Wysocki" <rafael@kernel.org>,
        Len Brown <lenb@kernel.org>, linux-acpi@vger.kernel.org,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org
References: <20230320191956.1354602-1-jpiotrowski@linux.microsoft.com>
 <20230322154655.GDZBsi75f6LnQStxSp@fat_crate.local>
 <1d25221c-eaab-0f97-83aa-8b4fbe3a53ed@linux.microsoft.com>
 <20230322181541.GEZBtFzRAMcH9BAzUe@fat_crate.local>
 <ecf005b1-ddb9-da4c-4526-28df4806426c@linux.microsoft.com>
 <20230323152342.GFZBxu/m3u6aFUDY/7@fat_crate.local>
From:   Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
In-Reply-To: <20230323152342.GFZBxu/m3u6aFUDY/7@fat_crate.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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.
>