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

On Fri, Apr 25, 2025 at 06:52:59AM +0800, Edgecombe, Rick P wrote:
>On Thu, 2025-04-10 at 15:24 +0800, Chao Gao wrote:
>> +
>> +	/*
>> +	 * @user_size:
>> +	 *
>> +	 * The default UABI size of the register state buffer in guest
>> +	 * FPUs. Includes all supported user features except independent
>> +	 * managed features and features which have to be requested by
>> +	 * user space before usage.
>> +	 */
>> +	unsigned int user_size;
>> +
>> +	/*
>> +	 * @features:
>> +	 *
>> +	 * The default supported features bitmap in guest FPUs. Does not
>> +	 * include independent managed features and features which have to
>> +	 * be requested by user space before usage.
>> +	 */
>> +	u64 features;
>> +
>> +	/*
>> +	 * @user_features:
>> +	 *
>> +	 * Same as @features except only user xfeatures are included.
>> +	 */
>> +	u64 user_features;
>> +};
>
>Tracing through the code, it seems that fpu_user_cfg.default_features and
>guest_default_cfg.user_features are the same, leading to
>fpu_user_cfg.default_size and guest_default_cfg.user_size being also the same.

Right. This is primarily for readability and symmetry.

I slightly prefer __guest_fpstate_reset() in this series:

	fpstate->size		= guest_default_cfg.size;
	fpstate->user_size	= guest_default_cfg.user_size;
	fpstate->xfeatures	= guest_default_cfg.features;
	fpstate->user_xfeatures	= guest_default_cfg.user_features;

over this version:

	fpstate->size		= guest_default_cfg.size;
	fpstate->xfeatures	= guest_default_cfg.features;

	/*
	 * use fpu_user_cfg for user_* settings for compatibility of exiting
	 * uAPIs.
	 */
	fpstate->user_size	= fpu_user_cfg.user_size;
	fpstate->user_xfeatures	= fpu_user_cfg.default_features;

Referencing different structures for size/xfeatures and their user_*
counterparts is not elegant to me. The need for a comment indicates that
this chunk may cause confusion. And this pattern will repeat when
initializing fpu->guest_perm in fpstate_reset().

>
>In the later patches, it doesn't seem to change the "user" parts. These
>configurations end up controlling the default size and features that gets copied
>to userspace in KVM_SET_XSAVE. I guess today there is only one default size and
>feature set for xstate copied to userspace. The suggestion from Chang was that
>it makes the code more readable, but it seems like it also breaks apart a
>unified concept for no functional benefit.

In the future, the feature and size of the uABI buffer for guest FPUs may
differ from those of non-guest FPUs. Sean rejected the idea of saving/restoring
CET_S xstate in KVM partly because:

 :Especially because another big negative is that not utilizing XSTATE bleeds into
 :KVM's ABI.  Userspace has to be told to manually save+restore MSRs instead of just
 :letting KVM_{G,S}ET_XSAVE handle the state.  And that will create a bit of a
 :snafu if Linux does gain support for SSS.

*: https://lore.kernel.org/kvm/ZM1jV3UPL0AMpVDI@google.com/

[To be clear, it is not an issue caused by Chang's suggestion. v4 which adds
new members @guest_size @guest_default_features to fpu_state_config has the
same problem. i.e., fpu_user_cfg.guest_default_feaures is identical to
fpu_user_cfg.default_features, adding no functional benefit.]

>
>Maybe we don't need user_features or user_size here in vcpu_fpu_config? Or did I

I don't have a strong opinion on this. I am ok with dropping them. Do you have
a strong preference?

>get lost somewhere along the way in all the twists and turns that features and
>sizes go through.

No, your analysis is correct.

>
>