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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4a4b1f18d585c7799e5262453e4cfa2cf47c3175.camel@intel.com>
Date: Fri, 25 Apr 2025 16:09:29 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "Gao, Chao" <chao.gao@...el.com>
CC: "kvm@...r.kernel.org" <kvm@...r.kernel.org>, "ebiggers@...gle.com"
	<ebiggers@...gle.com>, "Hansen, Dave" <dave.hansen@...el.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>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Yang,
 Weijiang" <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>, "seanjc@...gle.com"
	<seanjc@...gle.com>, "Bae, Chang Seok" <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

On Fri, 2025-04-25 at 16:24 +0800, Chao Gao wrote:
> > 
> > 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.

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. (2) is an existing problem. But if we think KVM should have its own
feature set of bits for ABI purposes, it seems like maybe it should have some
dedicated consideration. 

I'd think we should not try to address it in this series. Let's stick to what
the current CET KVM series needs. Changing KVM_GET_XSAVE behavior or cleanup
could be a separate series.

>   And that will create a bit of a
>  :snafu if Linux does gain support for SSS.
> 
> *: https://lore.kernel.org/kvm/ZM1jV3UPL0AMpVDI@google.com/

I chatted with Xin about this a few weeks ago. It sounds like FRED bare metal
SSS will not need CET_S state, but it wasn't 100% clear.

>