Lazy FPU switching [was Re: Straw proposal: MI kthread vector/fp unit API]

[Taylor R Campbell <campbell+netbsd-tech-kern%mumble.net@localhost>]

[subject line changed because this has gone afield from the proposed
kthread flag]

> Date: Wed, 24 Jun 2020 06:36:17 +0200
> From: Martin Husemann <martin%duskware.de@localhost>
> 
> On Tue, Jun 23, 2020 at 11:14:30PM +0200, Jaromír Dole?ek wrote:
> > No lazy FPU save logic please. It was eradicated from x86 for a reason:
> > https://access.redhat.com/solutions/3485131
> 
> Taylor added code (in the proposed changes, not for general x86 context
> switches) to avoid leaks like that in his code (even at the cost of
> performance and even if the architecture would not be prone to this).

My proposed kthread_fpu_exit zeros the FPU registers when a kthread is
done using them, as does the MD logic that surrounds each individual
FPU-using subroutine in the riastradh-kernelcrypto topic (in the `AES
leaks, ...' thread) whether in an FPU-enabled kthread or not.

But I'm not saying that's an adequate solution to the Spectre-class
attacks on lazy FPU switching -- it just protects the secrets in the
FPU during kthread_fpu_enter/exit from Spectre gadgets involving the
FPU in other kernel logic after kthread_fpu_exit.

> > Same should really be done for SPARC.
> 
> I disagree with that globalization.
> 
> If we have proper analyzis that shows there is no gain, or a
> non-FPU-saving context switch never (or very rarely) happens we can
> consider removing the (IMO) small additional complexity of the lazy
> switch code.
> 
> But not without carefull upfront measurements.

We removed it in x86 because it turned out that one userland process
can read another userland process's secrets out of the FPU registers,
even across privilege boundaries.  The same leaks will apply to pretty
much any architecture with speculative execution.

x86 still avoids doing FPU save/restore for processes that don't use
the FPU at all -- that's a different issue, and it's not a security
issue, and whether or not there's a performance gain (these days, a
lot of userland code uses FPU/vector instructions), the complexity
cost is negligible: just skip saving if FPU is not in use, skip
restoring if FPU was not in use.