linux-kernel - [tip:x86/cpu] x86/entry/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: <tip-5bf0cab60ee2c730ec91ae0aabc3146bcfed138b@git.kernel.org>
Date:   Sat, 22 Jun 2019 03:11:55 -0700
From:   "tip-bot for Chang S. Bae" <tipbot@...or.com>
To:     linux-tip-commits@...r.kernel.org
Cc:     hpa@...or.com, tglx@...utronix.de, chang.seok.bae@...el.com,
        luto@...nel.org, ravi.v.shankar@...el.com,
        linux-kernel@...r.kernel.org, ak@...ux.intel.com, mingo@...nel.org
Subject: [tip:x86/cpu] x86/entry/64: Document GSBASE handling in the
 paranoid path

Commit-ID:  5bf0cab60ee2c730ec91ae0aabc3146bcfed138b
Gitweb:     https://git.kernel.org/tip/5bf0cab60ee2c730ec91ae0aabc3146bcfed138b
Author:     Chang S. Bae <chang.seok.bae@...el.com>
AuthorDate: Wed, 8 May 2019 03:02:28 -0700
Committer:  Thomas Gleixner <tglx@...utronix.de>
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 <chang.seok.bae@...el.com>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Cc: Andy Lutomirski <luto@...nel.org>
Cc: Andi Kleen <ak@...ux.intel.com>
Cc: Ravi Shankar <ravi.v.shankar@...el.com>
Cc: H. Peter Anvin <hpa@...or.com>
Link: https://lkml.kernel.org/r/1557309753-24073-14-git-send-email-chang.seok.bae@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 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.