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@xxxxxxxxxx/).
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
