From: Eric Biggers <ebiggers@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Jain@formenos.rohan.me.apana.org.au, Ayush <Ayush.Jain3@amd.com>,
Stephen Rothwell <sfr@canb.auug.org.au>, x86-ml <x86@kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
linux-crypto@vger.kernel.org
Subject: Re: [PATCH] crypto: lib/sha256 - Disable SIMD
Date: Fri, 16 May 2025 12:06:37 -0700 [thread overview]
Message-ID: <20250516190637.GA32835@sol> (raw)
In-Reply-To: <20250516181322.GGaCeAQjnIVQx_tX_R@fat_crate.local>
On Fri, May 16, 2025 at 08:13:22PM +0200, Borislav Petkov wrote:
> On Fri, May 16, 2025 at 10:03:16AM -0700, Eric Biggers wrote:
> > That's silly. We should just fix x86's irq_fpu_usable() to return false
> > before the CPU is properly initialized. It already checks a per-cpu bool, so
> > it shouldn't be too hard to fit that in.
>
> Probably.
>
> There's a fpu__init_cpu() call almost right after load_ucode_ap() which causes
> this thing.
>
> I'm not sure how much initialized stuff you need for SHA256 SIMD... perhaps
> swap fpu__init_cpu() and load_ucode_ap() calls after proper code audit whether
> that's ok.
>
> Or add a "is the FPU initialized" check, as you propose, which is probably
> easier.
>
> As always, the x86 CPU init path is nasty and needs careful auditing.
There are a few different ways in which __apply_microcode_amd() can get called:
__apply_microcode_amd
load_ucode_amd_bsp
load_ucode_bsp
x86_64_start_kernel
apply_microcode_amd
load_ucode_amd_ap
load_ucode_ap
start_secondary
microcode_ops::apply_microcode
load_secondary
__load_primary
reload_ucode_amd
reload_early_microcode
microcode_bsp_resume
mc_syscore_ops::resume
syscore_resume
__restore_processor_state
restore_processor_state
What would you say about going back to my earlier plan to make irq_fpu_usable()
return false when irqs_disabled(), like what arm64 does? (As I had in
https://lore.kernel.org/lkml/20250220051325.340691-2-ebiggers@kernel.org/).
I think that would handle all these cases, as well as others. We'd need to fix
__save_processor_state() to save the FPU state directly without pretending that
it's using kernel-mode FPU, but I don't know of any issues besides that. Then
we could also delete the irqs_disabled() checks that I added to
kernel_fpu_begin() and kernel_fpu_end().
- Eric
next prev parent reply other threads:[~2025-05-16 19:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-16 11:22 cryptodev linux-next splat Borislav Petkov
2025-05-16 11:34 ` Herbert Xu
2025-05-16 11:48 ` [PATCH] crypto: lib/sha256 - Disable SIMD Herbert Xu
2025-05-16 12:27 ` Borislav Petkov
2025-05-16 17:03 ` Eric Biggers
2025-05-16 18:13 ` Borislav Petkov
2025-05-16 19:06 ` Eric Biggers [this message]
2025-05-16 20:34 ` Thomas Gleixner
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=20250516190637.GA32835@sol \
--to=ebiggers@kernel.org \
--cc=Ayush.Jain3@amd.com \
--cc=Jain@formenos.rohan.me.apana.org.au \
--cc=bp@alien8.de \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=x86@kernel.org \
/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.