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: <2ed04dff-e778-46c6-bd5f-51295763af06@zytor.com>
Date: Mon, 25 Aug 2025 23:54:46 -0700
From: Xin Li <xin@...or.com>
To: Chao Gao <chao.gao@...el.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 8/24/2025 7:55 PM, Chao Gao wrote:
>> 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.

There is no problem as of now, because there are only two CET related bits
set in KVM_SUPPORTED_XSS.  So if !CET, the two bits are cleared thus
kvm_caps.supported_xss is 0, and kvm_load_guest_fpu() is never executed in
__msr_io().

However after any new bit is added to KVM_SUPPORTED_XSS in future, if !CET,
kvm_caps.supported_xss could be non-zero.  There should still be no problem
because we don't expect any access to CET MSRs.

The trouble comes with MSR_IA32_PL0_SSP when FRED and !CET, because it will
be accessed even !CET.  And we need to have to do the following:

static bool is_xstate_managed_msr(u32 index)
{
	switch (index) {
	case MSR_IA32_U_CET:
	case MSR_IA32_PL1_SSP ... MSR_IA32_PL3_SSP:
		return true;
	case MSR_IA32_PL0_SSP:
		return kvm_caps.supported_xss & XFEATURE_MASK_CET_USER &&
		       kvm_caps.supported_xss & XFEATURE_MASK_CET_KERNEL;
	default:
		return false;
	}
}

Then it makes more sense to handle all CET MSRs consistently.

Thanks!
      Xin