Messages in this thread Patch in this message | | | From | "Chang S. Bae" <> | Subject | [PATCH v7 13/18] x86/fsgsbase/64: Document GSBASE handling in the paranoid path | Date | Wed, 8 May 2019 03:02:28 -0700 |
| |
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
| |