# HG changeset patch
# User Taylor R Campbell <riastradh@NetBSD.org>
# Date 1593959045 0
#      Sun Jul 05 14:24:05 2020 +0000
# Branch trunk
# Node ID ccf3ee876dd2fa7edc8531fa6e52bbc168efa9ca
# Parent  e8460a9631ea2f044095d9142bfe51fe90253541
Restore the lwp's fpu state, not zeros.

We need to clear the fpu state anyway because it is likely to contain
secrets at this point.  Previously we set it to zeros, and then
issued stts to detect the mistake of further use of the fpu in
kernel.  But there must be some path I haven't identified yet that
doesn't do fpu_handle_deferred, leading to fpudna panics.

In any case, there's no benefit to restoring the fpu state twice
(once with zeros and once with the real data).

diff -r e8460a9631ea -r ccf3ee876dd2 sys/arch/x86/x86/fpu.c
--- a/sys/arch/x86/x86/fpu.c	Sun Jul 05 19:30:29 2020 +0000
+++ b/sys/arch/x86/x86/fpu.c	Sun Jul 05 14:24:05 2020 +0000
@@ -392,7 +392,10 @@ fpu_kern_enter(void)
 void
 fpu_kern_leave(void)
 {
-	static const union savefpu zero_fpu __aligned(64);
+	static const union savefpu zerofpu __aligned(64);
+	const union savefpu *savefpu;
+	struct lwp *l = curlwp;
+	struct pcb *pcb;
 	struct cpu_info *ci = curcpu();
 	int s;
 
@@ -400,17 +403,18 @@ fpu_kern_leave(void)
 	KASSERT(ci->ci_kfpu_spl != -1);
 
 	/*
-	 * Zero the fpu registers; otherwise we might leak secrets
-	 * through Spectre-class attacks to userland, even if there are
-	 * no bugs in fpu state management.
+	 * Restore the FPU state immediately to avoid leaking any
+	 * kernel secrets, or zero it if this is a kthread.
 	 */
-	fpu_area_restore(&zero_fpu, x86_xsave_features);
-
-	/*
-	 * Set CR0_TS again so that the kernel can't accidentally use
-	 * the FPU.
-	 */
-	stts();
+	if ((l->l_pflag & LP_INTR) && (l->l_switchto != NULL))
+		l = l->l_switchto;
+	if (l->l_flag & LW_SYSTEM) {
+		savefpu = &zerofpu;
+	} else {
+		pcb = lwp_getpcb(l);
+		savefpu = &pcb->pcb_savefpu;
+	}
+	fpu_area_restore(savefpu, x86_xsave_features);
 
 	s = ci->ci_kfpu_spl;
 	ci->ci_kfpu_spl = -1;