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]
Date:   Sat, 18 Mar 2023 17:15:01 -0700
From:   Rick Edgecombe <>
To:, "H . Peter Anvin" <>,
        Thomas Gleixner <>,
        Ingo Molnar <>,,,,,,
        Arnd Bergmann <>,
        Andy Lutomirski <>,
        Balbir Singh <>,
        Borislav Petkov <>,
        Cyrill Gorcunov <>,
        Dave Hansen <>,
        Eugene Syromiatnikov <>,
        Florian Weimer <>,
        "H . J . Lu" <>, Jann Horn <>,
        Jonathan Corbet <>,
        Kees Cook <>,
        Mike Kravetz <>,
        Nadav Amit <>,
        Oleg Nesterov <>, Pavel Machek <>,
        Peter Zijlstra <>,
        Randy Dunlap <>,
        Weijiang Yang <>,
        "Kirill A . Shutemov" <>,
        John Allen <>,,,,,,,,,,,
Subject: [PATCH v8 06/40] x86/fpu: Add helper for modifying xstate

Just like user xfeatures, supervisor xfeatures can be active in the
registers or present in the task FPU buffer. If the registers are
active, the registers can be modified directly. If the registers are
not active, the modification must be performed on the task FPU buffer.

When the state is not active, the kernel could perform modifications
directly to the buffer. But in order for it to do that, it needs
to know where in the buffer the specific state it wants to modify is
located. Doing this is not robust against optimizations that compact
the FPU buffer, as each access would require computing where in the
buffer it is.

The easiest way to modify supervisor xfeature data is to force restore
the registers and write directly to the MSRs. Often times this is just fine
anyway as the registers need to be restored before returning to userspace.
Do this for now, leaving buffer writing optimizations for the future.

Add a new function fpregs_lock_and_load() that can simultaneously call
fpregs_lock() and do this restore. Also perform some extra sanity
checks in this function since this will be used in non-fpu focused code.

Suggested-by: Thomas Gleixner <>
Signed-off-by: Rick Edgecombe <>
Reviewed-by: Kees Cook <>
Acked-by: Mike Rapoport (IBM) <>
Tested-by: Pengfei Xu <>
Tested-by: John Allen <>
Tested-by: Kees Cook <>

 - Drop "but appear to work" (Boris)

 - Fix spelling error (Boris)
 - Don't export fpregs_lock_and_load() (Boris)

 - Rename to fpregs_lock_and_load() to match the unlocking
   fpregs_unlock(). (Kees)
 - Elaborate in comment about helper. (Dave)

 - Drop optimization of writing directly the buffer, and change API
 - fpregs_lock_and_load() suggested by tglx
 - Some commit log verbiage from dhansen
 arch/x86/include/asm/fpu/api.h |  9 +++++++++
 arch/x86/kernel/fpu/core.c     | 18 ++++++++++++++++++
 2 files changed, 27 insertions(+)

diff --git a/arch/x86/include/asm/fpu/api.h b/arch/x86/include/asm/fpu/api.h
index 503a577814b2..aadc6893dcaa 100644
--- a/arch/x86/include/asm/fpu/api.h
+++ b/arch/x86/include/asm/fpu/api.h
@@ -82,6 +82,15 @@ static inline void fpregs_unlock(void)
+ * FPU state gets lazily restored before returning to userspace. So when in the
+ * kernel, the valid FPU state may be kept in the buffer. This function will force
+ * restore all the fpu state to the registers early if needed, and lock them from
+ * being automatically saved/restored. Then FPU state can be modified safely in the
+ * registers, before unlocking with fpregs_unlock().
+ */
+void fpregs_lock_and_load(void);
 extern void fpregs_assert_state_consistent(void);
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index caf33486dc5e..f851558b673f 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -753,6 +753,24 @@ void switch_fpu_return(void)
+void fpregs_lock_and_load(void)
+	/*
+	 * fpregs_lock() only disables preemption (mostly). So modifying state
+	 * in an interrupt could screw up some in progress fpregs operation.
+	 * Warn about it.
+	 */
+	WARN_ON_ONCE(!irq_fpu_usable());
+	WARN_ON_ONCE(current->flags & PF_KTHREAD);
+	fpregs_lock();
+	fpregs_assert_state_consistent();
+	if (test_thread_flag(TIF_NEED_FPU_LOAD))
+		fpregs_restore_userregs();
  * If current FPU state according to its tracking (loaded FPU context on this

Powered by blists - more mailing lists