linux-kernel - Re: [PATCH v3 09/10] 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]

Message-ID: <e15d1074-d5ec-431d-86e5-a58bc6297df8@intel.com>
Date: Sun, 9 Mar 2025 15:06:28 -0700
From: "Chang S. Bae" <chang.seok.bae@...el.com>
To: Chao Gao <chao.gao@...el.com>, <tglx@...utronix.de>,
	<dave.hansen@...el.com>, <x86@...nel.org>, <seanjc@...gle.com>,
	<pbonzini@...hat.com>, <linux-kernel@...r.kernel.org>, <kvm@...r.kernel.org>
CC: <peterz@...radead.org>, <rick.p.edgecombe@...el.com>,
	<weijiang.yang@...el.com>, <john.allen@....com>, <bp@...en8.de>
Subject: Re: [PATCH v3 09/10] x86/fpu/xstate: Introduce
 XFEATURE_MASK_KERNEL_DYNAMIC xfeature set

On 3/7/2025 8:41 AM, Chao Gao wrote:
> 
> Define a new XFEATURE_MASK_KERNEL_DYNAMIC mask to specify the features
> that can be optionally enabled by kernel components. This is similar to
> XFEATURE_MASK_USER_DYNAMIC in that it contains optional xfeatures that
> can allows the FPU buffer to be dynamically sized. The difference is that
> the KERNEL variant contains supervisor features and will be enabled by
> kernel components that need them, and not directly by the user. Currently
> it's used by KVM to configure guest dedicated fpstate for calculating
> the xfeature and fpstate storage size etc.
> 
> Kernel dynamic features are enabled for the guest FPU and disabled for
> the kernel FPU, effectively making them guest-only features.
> 
> Set XFEATURE_CET_KERNEL as the first kernel dynamic feature, as it is
> required only by the guest FPU for the upcoming CET virtualization
> support in KVM.

When introducing user dynamic features, AMX required a large state, so 
buffer reallocation for expansion was deferred until it was actually 
used. This introduction was associated with introducing a permission 
mechanism, which was expected to be requested by userspace.

For VCPU tasks, the userspace component (QEMU) requests permission [1], 
and buffer expansion then follows based on the exposed CPUID 
determination [2].

Now, regarding the new kernel dynamic features, I’m unsure whether this 
changelog or anything else sufficiently describes its semantics 
distintively. It appears that both permission grant and buffer 
allocation for the kernel dynamic feature occur at VCPU allocation time. 
However, this model differs from the deferred buffer expansion model for 
user dynamic features.

If the kernel dynamic feature model were to follow the same deferred 
reallocation approach as user dynamic features, buffer reallocation 
would be expected. In that case, I'd also question whether fpu_guest_cfg 
is truly necessary.

VCPU allocation could still rely on fpu_kernel_cfg, and fpu->guest_perm 
could be extrapolated from fpu->perm or fpu_kernel_cfg. Then, 
reallocation could proceed as usual based on the permission, extending 
fpu_enable_guest_xfd_features(), possibly renaming it to 
fpu_enable_dynamic_features().

That said, this is a relatively small state. Even if the intent was to 
introduce a new semantic model distinct from user dynamic features, it 
should be clearly documented to avoid confusion.

On the other hand, if the goal is rather to establish a new approach for 
handling a previously nonexistent set of guest-exclusive features, then 
the current approach remains somewhat convoluted without clear 
descriptions. Perhaps, I'm missing something.

Thanks,
Chang

[1] https://github.com/qemu/qemu/blob/master/target/i386/kvm/kvm.c#L6395
[2] 
https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kvm/cpuid.c#n195