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

[email protected]
Newsgroups gmane.linux.raid
Message-ID <[email protected]>
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 <[email protected]>

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/[email protected]?part=7
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.