All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Eric Biggers" <ebiggers@kernel.org>
Cc: linux-raid@vger.kernel.org, yukuai@fygo.io
Subject: Re: [PATCH 4/8] lib/crypto: x86: Stop using cpu_has_xfeatures()
Date: Fri, 26 Jun 2026 04:53:21 +0000	[thread overview]
Message-ID: <20260626045322.591EE1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260626043731.319287-5-ebiggers@kernel.org>

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 <ebiggers@kernel.org>

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/20260626043731.319287-1-ebiggers@kernel.org?part=4

  reply	other threads:[~2026-06-26  4:53 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26  4:37 [PATCH 0/8] x86: Remove cpu_has_xfeatures() and add AVX-512 xor_gen() Eric Biggers
2026-06-26  4:37 ` [PATCH 1/8] x86/fpu: Check for missing AVX and AVX-512 xstate bits Eric Biggers
2026-06-26  5:00   ` sashiko-bot
2026-06-26  5:39   ` Christoph Hellwig
2026-06-26  4:37 ` [PATCH 2/8] um: " Eric Biggers
2026-06-26  7:41   ` David Laight
2026-06-26  8:21     ` Anton Ivanov
2026-06-26 10:49       ` David Laight
2026-06-26 20:55         ` Eric Biggers
2026-06-26 21:33           ` David Laight
2026-06-26  4:37 ` [PATCH 3/8] crypto: x86 - Stop using cpu_has_xfeatures() Eric Biggers
2026-06-26  4:37 ` [PATCH 4/8] lib/crypto: x86: " Eric Biggers
2026-06-26  4:53   ` sashiko-bot [this message]
2026-06-26  4:37 ` [PATCH 5/8] lib/crc: " Eric Biggers
2026-06-26  4:37 ` [PATCH 6/8] x86/fpu: Remove cpu_has_xfeatures() Eric Biggers
2026-06-26  4:37 ` [PATCH 7/8] lib/raid/xor: x86: Remove redundant X86_FEATURE_OSXSAVE check Eric Biggers
2026-06-26  4:51   ` sashiko-bot
2026-06-26  5:40   ` Christoph Hellwig
2026-06-26  4:37 ` [PATCH 8/8] lib/raid/xor: x86: Add AVX-512 optimized xor_gen() Eric Biggers
2026-06-26  5:47   ` Christoph Hellwig
2026-06-26  5:47     ` Christoph Hellwig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260626045322.591EE1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yukuai@fygo.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.