x86/fpu/xstate: Restore supervisor states for signal return
authorYu-cheng Yu <yu-cheng.yu@intel.com>
Tue, 12 May 2020 14:54:44 +0000 (07:54 -0700)
committerBorislav Petkov <bp@suse.de>
Sat, 16 May 2020 10:20:50 +0000 (12:20 +0200)
commit55e00fb66fd5048f4a3ee357018fd26fc527abca
tree099bbdcdb05313b8b6df4f6fc0cd83bd07734f97
parent98265c17efa9f2279c59262cd27679aca12e0bb8
x86/fpu/xstate: Restore supervisor states for signal return

The signal return fast path directly restores user states from the user
buffer. Once that succeeds, restore supervisor states (but only when
they are not yet restored).

For the slow path, save supervisor states to preserve them across context
switches, and restore after the user states are restored.

The previous version has the overhead of an XSAVES in both the fast and the
slow paths.  It is addressed as the following:

- In the fast path, only do an XRSTORS.
- In the slow path, do a supervisor-state-only XSAVES, and relocate the
  buffer contents.

Some thoughts in the implementation:

- In the slow path, can any supervisor state become stale between
  save/restore?

  Answer: set_thread_flag(TIF_NEED_FPU_LOAD) protects the xstate buffer.

- In the slow path, can any code reference a stale supervisor state
  register between save/restore?

  Answer: In the current lazy-restore scheme, any reference to xstate
  registers needs fpregs_lock()/fpregs_unlock() and __fpregs_load_activate().

- Are there other options?

  One other option is eagerly restoring all supervisor states.

  Currently, CET user-mode states and ENQCMD's PASID do not need to be
  eagerly restored.  The upcoming CET kernel-mode states (24 bytes) need
  to be eagerly restored.  To me, eagerly restoring all supervisor states
  adds more overhead then benefit at this point.

Signed-off-by: Yu-cheng Yu <yu-cheng.yu@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://lkml.kernel.org/r/20200512145444.15483-11-yu-cheng.yu@intel.com
arch/x86/kernel/fpu/signal.c