All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.