linux-kernel - Re: [RFC PATCH 1/4] KVM: SEV: Publish supported SEV-SNP policy bits

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] [day] [month] [year] [list]

Message-ID: <90e75fb2-7c29-dfef-7cc9-adb5d8566eb5@amd.com>
Date: Wed, 10 Sep 2025 14:36:53 -0500
From: Tom Lendacky <thomas.lendacky@....com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org, x86@...nel.org,
 linux-crypto@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 Ingo Molnar <mingo@...hat.com>, Thomas Gleixner <tglx@...utronix.de>,
 Michael Roth <michael.roth@....com>, Ashish Kalra <ashish.kalra@....com>,
 Herbert Xu <herbert@...dor.apana.org.au>, David Miller <davem@...emloft.net>
Subject: Re: [RFC PATCH 1/4] KVM: SEV: Publish supported SEV-SNP policy bits

On 9/10/25 14:19, Sean Christopherson wrote:
> On Fri, Aug 22, 2025, Tom Lendacky wrote:
>> Define the set of policy bits that KVM currently knows as not requiring
>> any implementation support within KVM. Provide this value to userspace
>> via the KVM_GET_DEVICE_ATTR ioctl.
>>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@....com>
>> ---
>>  arch/x86/include/uapi/asm/kvm.h |  1 +
>>  arch/x86/kvm/svm/sev.c          | 11 ++++++++++-
>>  2 files changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
>> index 0f15d683817d..90e9c4551fa6 100644
>> --- a/arch/x86/include/uapi/asm/kvm.h
>> +++ b/arch/x86/include/uapi/asm/kvm.h
>> @@ -468,6 +468,7 @@ struct kvm_sync_regs {
>>  /* vendor-specific groups and attributes for system fd */
>>  #define KVM_X86_GRP_SEV			1
>>  #  define KVM_X86_SEV_VMSA_FEATURES	0
>> +#  define KVM_X86_SNP_POLICY_BITS	1
>>  
>>  struct kvm_vmx_nested_state_data {
>>  	__u8 vmcs12[KVM_STATE_NESTED_VMX_VMCS_SIZE];
>> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
>> index 2fbdebf79fbb..7e6ce092628a 100644
>> --- a/arch/x86/kvm/svm/sev.c
>> +++ b/arch/x86/kvm/svm/sev.c
>> @@ -78,6 +78,8 @@ static u64 sev_supported_vmsa_features;
>>  					 SNP_POLICY_MASK_DEBUG		| \
>>  					 SNP_POLICY_MASK_SINGLE_SOCKET)
>>  
>> +static u64 snp_supported_policy_bits;
> 
> This can be __ro_after_init.  Hmm, off topic, but I bet we can give most of the

In the current form, I agree. If/when we support dynamic SEV firmware
updates, we may want to re-evaluate the supported policy bits since
newer SEV firmware could have made new bits available.

Maybe instead we move the call to get the current SEV firmware supported
bits and ANDing of the KVM supported bits into sev_dev_get_attr() and
snp_launch_start()? The downside is it is possible that the supported
policy bits could change between the two calls by the VMM.

Thanks,
Tom

> variables confifugred by sev_hardware_setup() the same treatment.  And really
> off topic, I have a patch somewhere to convert a bunch of KVM variables from
> __read_mostly to __ro_after_init...