Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing `cpu_has_xfeatures()` causes a kernel #UD panic on systems advertising AVX without XSAVE.
--
commit c4725d088a9c170c27e417f42ccdfa48f567b845
Author: Eric Biggers <[email protected]>
lib/crypto: x86: Stop using cpu_has_xfeatures()
This commit removes calls to cpu_has_xfeatures() across the x86 crypto
library, relying entirely on boot_cpu_has() to check for features. The
assumption is that x86 explicitly clears AVX and AVX-512 flags if their
xfeatures are missing.
> diff --git a/lib/crypto/x86/poly1305.h b/lib/crypto/x86/poly1305.h
> index ee92e3740a787..b061b9926fa5d 100644
> --- a/lib/crypto/x86/poly1305.h
> +++ b/lib/crypto/x86/poly1305.h
> @@ -143,15 +143,12 @@ static void poly1305_emit(const struct poly1305_state *ctx,
> #define poly1305_mod_init_arch poly1305_mod_init_arch
> static void poly1305_mod_init_arch(void)
> {
> - if (boot_cpu_has(X86_FEATURE_AVX) &&
> - cpu_has_xfeatures(XFEATURE_MASK_SSE | XFEATURE_MASK_YMM, NULL))
> + if (boot_cpu_has(X86_FEATURE_AVX))
> static_branch_enable(&poly1305_use_avx);
[Severity: High]
Will this cause a invalid opcode panic on systems advertising AVX without XSAVE
such as virtualized environments using a missing xsave cpu flag?
If XSAVE is missing natively, fpu__init_system_xstate() in
arch/x86/kernel/fpu/xstate.c returns early without clearing features:
arch/x86/kernel/fpu/xstate.c:fpu__init_system_xstate() {
...
if (!boot_cpu_has(X86_FEATURE_XSAVE)) {
pr_info("x86/fpu: x87 FPU will use %s\n",
boot_cpu_has(X86_FEATURE_FXSR) ? "FXSAVE" : "FSAVE");
return;
}
...
}
This early return bypasses clear_cpu_caps_with_missing_xfeatures(). Since
the CPUID dependency enforcement is only triggered when a feature is explicitly
cleared, X86_FEATURE_AVX is never cleared in this specific situation.
Without the cpu_has_xfeatures() check here, the crypto subsystems will see
boot_cpu_has(X86_FEATURE_AVX) as true and enable AVX instructions. Because
XSAVE is disabled, the OS never sets CR4.OSXSAVE=1, which can lead to a panic
when AVX instructions subsequently execute.
--
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=4
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.