Re: [PATCH 7/8] lib/raid/xor: x86: Remove redundant X86_FEATURE_OSXSAVE check

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Removing the X86_FEATURE_OSXSAVE check can cause an Invalid Opcode (#UD) kernel panic during XOR RAID operations if the CPU natively advertises AVX but not XSAVE.
--

commit 6fce8e80966a4c49b0b494779bd6206c6d6bed1f
Author: Eric Biggers <ebiggers@kernel.org>

lib/raid/xor: x86: Remove redundant X86_FEATURE_OSXSAVE check

This commit removes the X86_FEATURE_OSXSAVE check when selecting the AVX
XOR implementation, assuming X86_FEATURE_AVX implies X86_FEATURE_OSXSAVE.

> diff --git a/lib/raid/xor/x86/xor_arch.h b/lib/raid/xor/x86/xor_arch.h
> index 99fe85a213c66..991abe3f4bbda 100644
> --- a/lib/raid/xor/x86/xor_arch.h
> +++ b/lib/raid/xor/x86/xor_arch.h
> @@ -18,8 +18,7 @@ extern struct xor_block_template xor_block_avx;
>   */
>  static __always_inline void __init arch_xor_init(void)
>  {
> -	if (boot_cpu_has(X86_FEATURE_AVX) &&
> -	    boot_cpu_has(X86_FEATURE_OSXSAVE)) {
> +	if (boot_cpu_has(X86_FEATURE_AVX)) {
[Severity: High]
Can this lead to an Invalid Opcode (#UD) kernel panic during XOR RAID
operations if a CPU advertises AVX but not XSAVE?

If a hypervisor exposes AVX but hides XSAVE (for example, using QEMU's
-cpu host,-xsave flag), get_cpu_cap() still sets X86_FEATURE_AVX in
boot_cpu_data.

Although check_cpufeature_deps() detects the missing dependency, it only
issues a pr_warn_once warning without actually clearing X86_FEATURE_AVX.

During boot, fpu__init_system_xstate() evaluates
!boot_cpu_has(X86_FEATURE_XSAVE) as true and executes an early return.
This early return bypasses clear_cpu_caps_with_missing_xfeatures(), meaning
X86_FEATURE_AVX is never cleared by the kernel.

Since the X86_FEATURE_OSXSAVE check was removed here, arch_xor_init()
will forcibly select xor_block_avx based solely on X86_FEATURE_AVX.
When VEX-encoded AVX instructions are later executed, the CPU will throw an
Invalid Opcode (#UD) exception because CR4.OSXSAVE was never set to 1 by
the OS.

Is there another mechanism that guarantees X86_FEATURE_AVX is cleared in
this scenario, or should the X86_FEATURE_OSXSAVE check be retained to safely
ensure the OS has fully initialized and enabled XSAVE?

>  		xor_force(&xor_block_avx);
>  	} else if (IS_ENABLED(CONFIG_X86_64) || boot_cpu_has(X86_FEATURE_XMM)) {
>  		xor_register(&xor_block_sse);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260626043731.319287-1-ebiggers@kernel.org?part=7