linux-kernel - Re: [PATCH v5 3/7] x86/fpu/xstate: Differentiate default features for host and guest FPUs

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: <aA71VD0NgLZMmNGi@intel.com>
Date: Mon, 28 Apr 2025 11:26:12 +0800
From: Chao Gao <chao.gao@...el.com>
To: Sean Christopherson <seanjc@...gle.com>
CC: Rick P Edgecombe <rick.p.edgecombe@...el.com>, "kvm@...r.kernel.org"
	<kvm@...r.kernel.org>, "ebiggers@...gle.com" <ebiggers@...gle.com>, "Dave
 Hansen" <dave.hansen@...el.com>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, Stanislav Spassov <stanspas@...zon.de>,
	"levymitchell0@...il.com" <levymitchell0@...il.com>,
	"samuel.holland@...ive.com" <samuel.holland@...ive.com>, Xin3 Li
	<xin3.li@...el.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, Weijiang Yang <weijiang.yang@...el.com>,
	"mingo@...hat.com" <mingo@...hat.com>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "tglx@...utronix.de" <tglx@...utronix.de>,
	"john.allen@....com" <john.allen@....com>, "mlevitsk@...hat.com"
	<mlevitsk@...hat.com>, Chang Seok Bae <chang.seok.bae@...el.com>,
	"vigbalas@....com" <vigbalas@....com>, "peterz@...radead.org"
	<peterz@...radead.org>, "hpa@...or.com" <hpa@...or.com>, "bp@...en8.de"
	<bp@...en8.de>, "aruna.ramakrishna@...cle.com"
	<aruna.ramakrishna@...cle.com>, "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v5 3/7] x86/fpu/xstate: Differentiate default features
 for host and guest FPUs

>> Hmm, interesting. I guess there are two things.
>> 1. Should CET_S be part of KVM_GET_XSAVE instead of via MSRs ioctls? It never
>> was in the KVM CET patches.
>> 2. A feature mask far away in the FPU code controls KVM's xsave ABI.
>> 
>> For (1), does any userspace depend on their not being supervisor features? (i.e.
>> tries to restore the guest FPU for emulation or something). There probably are
>> some advantages to keeping supervisor features out of it, or at least a separate
>> ioctl.
>
>CET_S probably shouldn't be in XSAVE ABI, because that would technically leak
>kernel state to userspace for the non-KVM use case.

ok. thanks for the clarification.

>I assume the kernel has
>bigger problems if CET_S is somehow tied to a userspace task.

To be clear, CET_S here refers to the CET supervisor state, which includes SSP
pointers for privilege levels 0 through 2. The IA32_S_CET MSR is not part of
that state.

>
>For KVM, it's just the one MSR, and KVM needs to support save/restore of that MSR
>no matter what, so supporting it via XSAVE would be more work, a bit sketchy, and
>create yet another way for userspace to do weird things when saving/restoring vCPU
>state.

Agreed. One more issue of including CET_S into KVM_GET/SET_XSAVE{2} is:

XSAVE UABI buffers adhere to the standard format defined by the SDM, which
never includes supervisor states. Attempting to incorporate supervisor states
into UABI buffers would lead to many issues, such as deviating from the
standard format and the need to define offsets for each supervisor state.