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: <aAwdQ759Y6V7SGhv@google.com>
Date: Fri, 25 Apr 2025 16:48:16 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Rick P Edgecombe <rick.p.edgecombe@...el.com>
Cc: Chao Gao <chao.gao@...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

On Fri, Apr 25, 2025, Rick P Edgecombe wrote:
> 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.

CET_S probably shouldn't be in XSAVE ABI, because that would technically leak
kernel state to userspace for the non-KVM use case.  I assume the kernel has
bigger problems if CET_S is somehow tied to a userspace task.

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.

> (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. 

Nah, don't bother.  The kernel needs to solve the exact same problems for the
signal ABI, I don't see any reason to generate more work.  From a validation
coverage perspective, I see a lot of value in shared code.