From: "Chang S. Bae" <chang.seok....@intel.com> On FSGSBASE systems, the way to handle GS base in the paranoid path is different from the existing SWAPGS-based entry/exit path handling. Document the reason and what has to be done for FSGSBASE enabled systems.
Signed-off-by: Chang S. Bae <chang.seok....@intel.com> Signed-off-by: Sasha Levin <sas...@kernel.org> Reviewed-by: Tony Luck <tony.l...@intel.com> Cc: Thomas Gleixner <t...@linutronix.de> Cc: Borislav Petkov <b...@alien8.de> Cc: Andy Lutomirski <l...@kernel.org> Cc: H. Peter Anvin <h...@zytor.com> Cc: Dave Hansen <dave.han...@intel.com> Cc: Tony Luck <tony.l...@intel.com> Cc: Andi Kleen <a...@linux.intel.com> --- Documentation/x86/entry_64.rst | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/Documentation/x86/entry_64.rst b/Documentation/x86/entry_64.rst index a48b3f6ebbe87..0499a40723af3 100644 --- a/Documentation/x86/entry_64.rst +++ b/Documentation/x86/entry_64.rst @@ -108,3 +108,12 @@ We try to only use IST entries and the paranoid entry code for vectors that absolutely need the more expensive check for the GS base - and we generate all 'normal' entry points with the regular (faster) paranoid=0 variant. + +On FSGSBASE systems, however, user space can set GS without kernel +interaction. It means the value of GS base itself does not imply anything, +whether a kernel value or a user space value. So, there is no longer a safe +way to check whether the exception is entering from user mode or kernel +mode in the paranoid entry code path. So the GS base value needs to be read +out, saved and the kernel GS base value written. On exit, the saved GS base +value needs to be restored unconditionally. The non-paranoid entry/exit +code still uses SWAPGS unconditionally as the state is known. -- 2.20.1
