linux-kernel - [PATCH v7 13/18] x86/fsgsbase/64: Document GSBASE handling in the paranoid path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1557309753-24073-14-git-send-email-chang.seok.bae@intel.com>
Date:   Wed,  8 May 2019 03:02:28 -0700
From:   "Chang S. Bae" <chang.seok.bae@...el.com>
To:     Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>,
        "H . Peter Anvin" <hpa@...or.com>, Andi Kleen <ak@...ux.intel.com>
Cc:     Ravi Shankar <ravi.v.shankar@...el.com>,
        "Chang S . Bae" <chang.seok.bae@...el.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: [PATCH v7 13/18] x86/fsgsbase/64: Document GSBASE handling in the paranoid path

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@...el.com>
Cc: Andy Lutomirski <luto@...nel.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: Ingo Molnar <mingo@...nel.org>
Cc: H. Peter Anvin <hpa@...or.com>
Cc: Andi Kleen <ak@...ux.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