linux-kernel - Re: [PATCH v4 2/5] crypto: ccp: Add support for SNP_FEATURE

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: <9cac6024-2e13-12ae-24f2-2f1668691935@amd.com>
Date: Thu, 5 Jun 2025 10:51:11 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: "Kalra, Ashish" <ashish.kalra@....com>, seanjc@...gle.com,
 pbonzini@...hat.com, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com, hpa@...or.com, herbert@...dor.apana.org.au
Cc: x86@...nel.org, john.allen@....com, davem@...emloft.net,
 michael.roth@....com, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-crypto@...r.kernel.org
Subject: Re: [PATCH v4 2/5] crypto: ccp: Add support for SNP_FEATURE_INFO
 command

On 6/4/25 17:52, Kalra, Ashish wrote:
> Hello Tom,
> 
> On 6/3/2025 10:21 AM, Tom Lendacky wrote:
>> On 5/19/25 18:56, Ashish Kalra wrote:
>>> From: Ashish Kalra <ashish.kalra@....com>
>>>
>>>
>>> Switch to using SNP platform status instead of SEV platform status if
>>> SNP is enabled and cache SNP platform status and feature information
>>> from CPUID 0x8000_0024, sub-function 0, in the sev_device structure.
>>
>> Since the SEV platform status and SNP platform status differ, I think this
>> patch should be split into two separate patches.
>>
>> The first first patch would cache the current SEV platform status return
>> structure and eliminate the separate state field (as state is unique
>> between SEV and SNP).
> 
> Eliminate the state field ? 
> 
> But isn't the sev_device->state field used also as driver's internal state information
> and not directly mapped to platform status, except the initial state is the platform state 
> on module load, so why to remove the field altogether ?

Well the state of SEV and SNP are different, so they need to be tracked
separately (or at least better clarified in the code that the current
state field is tracking the SEV state). Since the state field is part of
the platform status, you can just update that field. Not sure what it will
look like.

The current state is only SEV related because SNP only has UNINIT and INIT
and so the snp_initialized flag is used instead.

Thanks,
Tom

>