Commit-ID: 5bf0cab60ee2c730ec91ae0aabc3146bcfed138b Gitweb: https://git.kernel.org/tip/5bf0cab60ee2c730ec91ae0aabc3146bcfed138b Author: Chang S. Bae <[email protected]> AuthorDate: Wed, 8 May 2019 03:02:28 -0700 Committer: Thomas Gleixner <[email protected]> CommitDate: Sat, 22 Jun 2019 11:38:55 +0200
x86/entry/64: Document GSBASE handling in the paranoid path On a FSGSBASE system, the way to handle GSBASE 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. [ tglx: Massaged doc and changelog ] Signed-off-by: Chang S. Bae <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Andi Kleen <[email protected]> Cc: Ravi Shankar <[email protected]> Cc: H. Peter Anvin <[email protected]> Link: https://lkml.kernel.org/r/[email protected] --- 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 a48b3f6ebbe8..b87c1d816aea 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 a FSGSBASE system, 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 GSBASE value needs to be read +out, saved and the kernel GSBASE value written. On exit the saved GSBASE +value needs to be restored unconditionally. The non paranoid entry/exit +code still uses SWAPGS unconditionally as the state is known.
