linux-kernel - Re: [PATCH v13 05/21] KVM: x86: Load guest FPU state when access XSAVE-managed MSRs

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: <aKvP2AHKYeQCPm0x@intel.com>
Date: Mon, 25 Aug 2025 10:55:09 +0800
From: Chao Gao <chao.gao@...el.com>
To: Xin Li <xin@...or.com>
CC: <kvm@...r.kernel.org>, <linux-kernel@...r.kernel.org>, <bp@...en8.de>,
	<dave.hansen@...ux.intel.com>, <hpa@...or.com>, <john.allen@....com>,
	<mingo@...hat.com>, <minipli@...ecurity.net>, <mlevitsk@...hat.com>,
	<pbonzini@...hat.com>, <rick.p.edgecombe@...el.com>, <seanjc@...gle.com>,
	<tglx@...utronix.de>, <weijiang.yang@...el.com>, <x86@...nel.org>
Subject: Re: [PATCH v13 05/21] KVM: x86: Load guest FPU state when access
 XSAVE-managed MSRs

On Sun, Aug 24, 2025 at 06:52:55PM -0700, Xin Li wrote:
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 6b01c6e9330e..799ac76679c9 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -4566,6 +4569,21 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>>   }
>>   EXPORT_SYMBOL_GPL(kvm_get_msr_common);
>> +/*
>> + *  Returns true if the MSR in question is managed via XSTATE, i.e. is context
>> + *  switched with the rest of guest FPU state.
>> + */
>> +static bool is_xstate_managed_msr(u32 index)
>> +{
>> +	switch (index) {
>> +	case MSR_IA32_U_CET:
>
>
>Why MSR_IA32_S_CET is not included here?

Emm. I didn't think about this.

MSR_IA32_S_CET is read from or written to a dedicated VMCS/B field, so KVM
doesn't need to load the guest FPU to access MSR_IA32_S_CET. This pairs with
the kvm_{get,set}_xstate_msr() in kvm_{get,set}_msr_common().

That said, userspace writes can indeed cause an inconsistency between the guest
FPU and VMCS fields regarding MSR_IA32_S_CET. If migration occurs right after a
userspace write (without a VM-entry, which would bring them in sync) and
userspace just restores MSR_IA32_S_CET from the guest FPU, the write before
migration could be lost.

If that migration issue is a practical problem, I think MSR_IA32_S_CET should
be included here, and we need to perform a kvm_set_xstate_msr() after writing
to the VMCS/B.

>
>
>> +	case MSR_IA32_PL0_SSP ... MSR_IA32_PL3_SSP:
>> +		return true;
>> +	default:
>> +		return false;
>> +	}
>> +}
>
>
>Is it better to do?
>
>static bool is_xstate_managed_msr(u32 index)
>{
>         if (!kvm_caps.supported_xss)
>                 return false;
>
>         switch (index) {
>         case MSR_IA32_U_CET:
>         case MSR_IA32_S_CET:
>         case MSR_IA32_PL1_SSP ... MSR_IA32_PL3_SSP:
>                 return kvm_caps.supported_xss & XFEATURE_MASK_CET_USER &&
>                        kvm_caps.supported_xss & XFEATURE_MASK_CET_KERNEL;
>         default:
>                 return false;

This will duplicate checks in other functions. I slightly prefer to keep this
function super simple and do all capability checks in __kvm_{set,get}_msr()
or kvm_emulate_msr_{write,read}.

>         }
>}
>
>And it would be obvious how to add new MSRs related to other XFEATURE bits.

Just return true for all those MSRs, regardless of host capabilities. If
kvm_caps doesn't support them, those MSRs are not advertised to userspace
either (see kvm_probe_msr_to_save()). Loading or putting the guest FPU when
userspace attempts to read/write those unsupported MSRs shouldn't cause any
performance issues, as userspace is unlikely to access them in hot paths.

>
>Thanks!
>    Xin