linux-kernel - Re: [PATCH 3/3] x86/fpu: Don't support kernel-mode FPU when irqs

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aCsqyrHdMWlU3yc0@gmail.com>
Date: Mon, 19 May 2025 14:57:46 +0200
From: Ingo Molnar <mingo@...nel.org>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Eric Biggers <ebiggers@...nel.org>, x86@...nel.org,
	linux-kernel@...r.kernel.org, linux-crypto@...r.kernel.org,
	linux-pm@...r.kernel.org, Borislav Petkov <bp@...en8.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ayush Jain <Ayush.Jain3@....com>,
	Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [PATCH 3/3] x86/fpu: Don't support kernel-mode FPU when
 irqs_disabled()


* Ard Biesheuvel <ardb@...nel.org> wrote:

> On Mon, 19 May 2025 at 10:06, Ingo Molnar <mingo@...nel.org> wrote:
> >
> >
> > * Eric Biggers <ebiggers@...nel.org> wrote:
> >
> > > > # echo PANIC > /sys/kernel/debug/provoke-crash/DIRECT
> > > >
> > > > Another case that likely executes with IRQs disabled (but I haven't
> > > > double checked) is reset_system(), which may return with an error, or
> > > > reboot/poweroff the machine and never return.
> > >
> > > That makes sense to me.  preempt_disable() and preempt_enable() are already
> > > allowed when IRQs are disabled, and I'm not sure why local_bh_disable() and
> > > local_bh_enable() are different.
> >
> > Because local_bh_enable() may run softirq handlers immediately if
> > there's pending softirqs, which shouldn't be done in hardirq context.
> >
> 
> Sure, but why is that mandatory?
>
> 
> preempt_disable() has preempt_enable() and preempt_enable_no_resched()
> counterparts.

> [...] Could we have a local_bh_enable_no_xxx() version that 
> re-enables async softirq processing on the current CPU but does not 
> kick off a synchronous processing run?

Yes, that's what __local_bh_enable() does, but if used it for 
kernel_fpu_end() we'd be introducing random softirq processing 
latencies. The softirq execution model is for softirqs to be 
immediately executed after local_bh_enable(), and various networking 
code is tuned to that behavior.

You can try talking the networking folks into an asynchronous 
local_bh_enable() executed on the next IRQ or the next scheduler tick 
or so, but it's a non-trivial behavioral change. It would probably also 
need user-return callback activation.

I'm pretty sure that the naive implementation would increase LAN ping 
latencies by +4 msecs on a typical distro kernel.

Thanks,

	Ingo