linux-kernel - Re: [PATCH v10 04/27] x86/fpu/xstate: Introduce XFEATURE_MASK_KERNEL

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]

Date: Thu, 2 May 2024 10:46:27 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Sean Christopherson <seanjc@...gle.com>,
 Yang Weijiang <weijiang.yang@...el.com>
Cc: pbonzini@...hat.com, x86@...nel.org, kvm@...r.kernel.org,
 linux-kernel@...r.kernel.org, peterz@...radead.org, chao.gao@...el.com,
 rick.p.edgecombe@...el.com, mlevitsk@...hat.com, john.allen@....com
Subject: Re: [PATCH v10 04/27] x86/fpu/xstate: Introduce
 XFEATURE_MASK_KERNEL_DYNAMIC xfeature set

On 5/1/24 11:45, Sean Christopherson wrote:
> On Sun, Feb 18, 2024, Yang Weijiang wrote:
>> Define a new XFEATURE_MASK_KERNEL_DYNAMIC mask to specify the features
> I still don't understand why this is being called DYNAMIC.  CET_SS isn't dynamic,
> as KVM is _always_ allowed to save/restore CET_SS, i.e. whether or not KVM can
> expose CET_SS to a guest is a static, boot-time decision.  Whether or not a guest
> XSS actually enables CET_SS is "dynamic", but that's true of literally every
> xfeature in XCR0 and XSS.
> 
> XFEATURE_MASK_XTILE_DATA is labeled as dynamic because userspace has to explicitly
> request that XTILE_DATA be enabled, and thus whether or not KVM is allowed to
> expose XTILE_DATA to the guest is a dynamic, runtime decision.
> 
> So IMO, the umbrella macro should be XFEATURE_MASK_KERNEL_GUEST_ONLY.

Here's how I got that naming.  First, "static" features are always
there.  "Dynamic" features might or might not be there.  I was also much
more focused on what's in the XSAVE buffer than on the enabling itself,
which are _slightly_ different.

Then, it's a matter of whether the feature is user or supervisor.  The
kernel might need new state for multiple reasons.  Think of LBR state as
an example.  The kernel might want LBR state around for perf _or_ so it
can be exposed to a guest.

I just didn't want to tie it to "GUEST" too much in case we have more of
these things come along that get used for things unrelated to KVM.
Obviously, at this point, we've only got one and KVM is the only user so
the delta that I was worried about doesn't actually exist.

So I still prefer calling it "KERNEL" over "GUEST".  But I also don't
feel strongly about it and I've said my peace.  I won't NAK it one way
or the other.