lkml.org 
[lkml]   [2019]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Subject[PATCH v7 13/18] x86/fsgsbase/64: Document GSBASE handling in the paranoid path
Date
On a FSGSBASE system, the way to handle GSBASE in the paranoid path
will be different from the existing SWAPGS-based. Document the reason
and what is done by the (new) GSBASE handling. In non-paranoid path,
it will keep working exactly like it does today.

Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Andi Kleen <ak@linux.intel.com>
---
Documentation/x86/entry_64.txt | 17 +++++++++++++++++
1 file changed, 17 insertions(+)

diff --git a/Documentation/x86/entry_64.txt b/Documentation/x86/entry_64.txt
index c1df8eb..2878c56 100644
--- a/Documentation/x86/entry_64.txt
+++ b/Documentation/x86/entry_64.txt
@@ -102,3 +102,20 @@ 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 safe way to check if entering from user mode to kernel mode.
+Instead, this way handles GS base properly with FSGSBASE:
+
+On entry:
+ rdgsbase %rbx
+ GET_PERCPU_BASE %rax /* see the details in calling.h */
+ wrgsbase %rax
+
+On exit:
+ wrgsbase %rbx
+
+Obviously, for the non-paranoid path, it all keeps working exactly
+likt it does without FSGSBASE.
\ No newline at end of file
--
2.7.4
\
 
 \ /
  Last update: 2019-05-08 19:04    [W:0.207 / U:4.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site