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: <aMDohALPiu+cwO7G@intel.com>
Date: Wed, 10 Sep 2025 10:55:00 +0800
From: Chao Gao <chao.gao@...el.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: Xin Li <xin@...or.com>, <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>, <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 Tue, Sep 09, 2025 at 01:03:43PM -0700, Sean Christopherson wrote:
>On Tue, Sep 09, 2025, Chao Gao wrote:
>> On Mon, Aug 25, 2025 at 10:55:20AM +0800, Chao Gao wrote:
>> >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?
>
>Because the guest's S_CET must *never* be resident in harware while running in
>the host.  Doing so would create an egregious security issue due to letting the
>guest disabled IBT and/or shadow stacks, or alternatively crash the host by
>enabling one or the other.

+1000

I completely missed this point.

>
>Having guest MSR_IA32_PL[0-3]_SSP resident in hardware while the _kernel_ is
>running is safe, because those MSRs are only consumed on transitions to lower
>privilege levels, i.e. from KVM's perspective, they're effectively user-return
>MSRs that get restored on exit to userspace thanks to kvm_{load,put}_guest_fpu()
>context switching between VMM and guest state (if the vCPU task is preempted,
>the normal context switch code handles swapping state between tasks, it's only
>the VMM vs. guest state that needs dedicated handling since they are the same
>task).
>
>Context switching S_CET as part of XRSTORS very, VERY subtly works by virtue of
>S_CET already being loaded with the host's value on VM-Exit.  I.e. the value
>saved into guest FPU state is always the host's value, and thus the value loaded
>from guest FPU state is always the host's value.

Looks like the host's value for a given vCPU should be constant here. I'm not
sure if this will change in the future, but I think it's unlikely.

>
>And because all of that isn't enough, the final wrinkle is that KVM_{G,S}ET_XSAVE
>only operate on xcr0 / user state, i.e. don't allow userspace to load supervisor
>(S_CET) state into the kernel.

Yes. userspace cannot see supervisor state in guest FPU and should read guest's
S_CET/MSR_IA32_PL[0-3]SSP via KVM_GET_MSRS or KVM_GET_ONE_REG.