# 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 2221a0c6c08a6757665b26e4816d42ee15a38263
# Parent  3df15d379c93a158378a444b2e2f1396eb6dc545
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 3df15d379c93 -r 2221a0c6c08a sys/arch/x86/x86/fpu.c
--- a/sys/arch/x86/x86/fpu.c	Sat Jul 04 12:04:15 2020 +0000
+++ b/sys/arch/x86/x86/fpu.c	Sun Jul 05 14:24:05 2020 +0000
@@ -392,7 +392,8 @@ fpu_kern_enter(void)
 void
 fpu_kern_leave(void)
 {
-	static const union savefpu zero_fpu __aligned(64);
+	struct lwp *l = curlwp;
+	struct pcb *pcb;
 	struct cpu_info *ci = curcpu();
 	int s;
 
@@ -400,17 +401,13 @@ 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.
 	 */
-	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;
+	pcb = lwp_getpcb(l);
+	fpu_area_restore(&pcb->pcb_savefpu, x86_xsave_features);
 
 	s = ci->ci_kfpu_spl;
 	ci->ci_kfpu_spl = -1;