linux-kernel - Re: [PATCH v7 01/10] KVM: SEV: Disable SEV-SNP support on initialization failure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b0fe42da-b257-bf1a-94e5-77cd8c090341@amd.com>
Date: Tue, 25 Feb 2025 13:09:34 -0600
From: Tom Lendacky <thomas.lendacky@....com>
To: "Pratik R. Sampat" <prsampat@....com>, linux-kernel@...r.kernel.org,
 x86@...nel.org, kvm@...r.kernel.org, linux-crypto@...r.kernel.org,
 linux-kselftest@...r.kernel.org
Cc: seanjc@...gle.com, pbonzini@...hat.com, tglx@...utronix.de,
 mingo@...hat.com, bp@...en8.de, dave.hansen@...ux.intel.com,
 shuah@...nel.org, pgonda@...gle.com, ashish.kalra@....com, nikunj@....com,
 pankaj.gupta@....com, michael.roth@....com, sraithal@....com
Subject: Re: [PATCH v7 01/10] KVM: SEV: Disable SEV-SNP support on
 initialization failure

On 2/25/25 11:45, Pratik R. Sampat wrote:
> On 2/25/2025 10:41 AM, Pratik R. Sampat wrote:
>> Hi Tom,
>>
>> On 2/24/2025 3:28 PM, Tom Lendacky wrote:
>>> On 2/21/25 15:01, Pratik R. Sampat wrote:
>>>> During platform init, SNP initialization may fail for several reasons,
>>>> such as firmware command failures and incompatible versions. However,
>>>> the KVM capability may continue to advertise support for it. Export this
>>>> information to KVM and withdraw SEV-SNP support if has not been
>>>> successfully initialized.
>>>
>>> Hmmm... rather than creating a new API, can you just issue an
>>> SNP_PLATFORM_STATUS command and see if the SNP is not in the UNINIT state?
>>>
>>
>> Although reading sev->snp_initialized is probably cheaper to do, it is
>> cleaner to query the platform status.
>>
>> Querying SNP_PLATFORM_STATUS requires the pages to transition to
>> firmware-owned and back, and the helpers for it are implemented within
>> sev-dev.c. So, similar to sev_platform_status(), I'm thinking it is
>> probably better to create the snp_platform_status() API as well and use
>> that within KVM to check the state.
>>
> 
> Although I am guessing the initial intent was to not have an API exposed
> at all from CCP and only make the SNP_PLATFORM_STATUS call instead?
> 
> Since that may not be cleanly possible (we have helpers for page state
> conversions such as rmp_mark_pages_firmware() in ccp) without
> duplicating functionality in KVM as well, I guess the question really
> boils down to whether we export the cheaper snp_initialized() or the
> snp_platform_status() API instead?

Taking a closer look, we do already have APIs that KVM uses to allocate
firmware pages (output pages for SNP APIs) that can be used:
snp_alloc_firmware_page() and snp_free_firmware_page().

I think that should be enough to use sev_do_cmd() to perform the
SEV_CMD_SNP_PLATFORM_STATUS command without exposing a new API.

Thanks,
Tom

> 
> Thanks again!
> Pratik