linux-kernel - Re: [RFC PATCH 1/2] x86/fpu: make kernel-mode FPU reliably usable in softirqs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMj1kXH8ABcuUzPfAC=A6hzUvo+jPvWfphTtJqgGCTpbegAi0g@mail.gmail.com>
Date: Fri, 28 Feb 2025 13:39:48 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: Eric Biggers <ebiggers@...nel.org>
Cc: x86@...nel.org, linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Ben Greear <greearb@...delatech.com>, Xiao Liang <shaw.leon@...il.com>, 
	Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, Andy Lutomirski <luto@...nel.org>, 
	"Jason A . Donenfeld" <Jason@...c4.com>
Subject: Re: [RFC PATCH 1/2] x86/fpu: make kernel-mode FPU reliably usable in softirqs

On Fri, 28 Feb 2025 at 04:59, Eric Biggers <ebiggers@...nel.org> wrote:
>
> On Wed, Feb 19, 2025 at 09:13:24PM -0800, Eric Biggers wrote:
> > To comply with the requirements of local_bh_disable and local_bh_enable,
> > this change also removes support for kernel-mode FPU in hardirq context
> > or with hardirqs disabled.  This should not be a problem, though.  There
> > does not appear to be any use case for kernel-mode FPU in such contexts,
> > and notably arm64 and riscv already have these same conditions.
>
> I found a problem with this assumption: the system suspend and resume code calls
> kernel_fpu_begin() and kernel_fpu_end() with hardirqs disabled.  See
> __save_processor_state() and __restore_processor_state() in
> arch/x86/power/cpu.c.  That triggers the WARN_ON_FPU(!irq_fpu_usable()).
>
> I think there are two directions we could go with this: either choose a solution
> that keeps kernel_fpu_begin() usable with hardirqs disabled;

I still owe you an investigation into how this interoperates with EFI
runtime services, but it appears there are cases (efi-pstore on an
OOPS) where EFI SetVariable() might be invoked with IRQs disabled.
arm64 has a special case for EFI runtime calls made under conditions
where SIMD may not be used, and essentially just preserves and
restores the entire state.

It is rather unfortunate that this is needed, but the UEFI spec
permits runtime service implementations to use XMM registers so there
is no way around this AFAIK.


> or change
> __save_processor_state() and __restore_processor_state() to save/restore the FPU
> registers directly, e.g. via save_fpregs_to_fpstate() and
> restore_fpregs_from_fpstate().  (Kernel-mode FPU isn't actually being used in
> this case, so a more direct save/restore might make sense here.)
>
> - Eric