linux-kernel - [tip:x86/urgent] x86/entry: Add some paranoid entry/exit CR3 handling comments

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-next>] [day] [month] [year] [list]

Date:   Sun, 14 Oct 2018 02:17:10 -0700
From:   tip-bot for Dave Hansen <tipbot@...or.com>
To:     linux-tip-commits@...r.kernel.org
Cc:     bp@...en8.de, linux-kernel@...r.kernel.org, mingo@...nel.org,
        luto@...nel.org, dave.hansen@...ux.intel.com, hpa@...or.com,
        tglx@...utronix.de
Subject: [tip:x86/urgent] x86/entry: Add some paranoid entry/exit CR3
 handling comments

Commit-ID:  16561f27f94e6193ee8f5b9b74801e1668c86efc
Gitweb:     https://git.kernel.org/tip/16561f27f94e6193ee8f5b9b74801e1668c86efc
Author:     Dave Hansen <dave.hansen@...ux.intel.com>
AuthorDate: Fri, 12 Oct 2018 16:21:18 -0700
Committer:  Thomas Gleixner <tglx@...utronix.de>
CommitDate: Sun, 14 Oct 2018 11:11:22 +0200

x86/entry: Add some paranoid entry/exit CR3 handling comments

Andi Kleen was just asking me about the NMI CR3 handling and why
we restore it unconditionally.  I was *sure* we had documented it
well.  We did not.

Add some documentation.  We have common entry code where the CR3
value is stashed, but three places in two big code paths where we
restore it.  I put bulk of the comments in this common path and
then refer to it from the other spots.

Signed-off-by: Dave Hansen <dave.hansen@...ux.intel.com>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
Cc: luto@...nel.org
Cc: bp@...en8.de
Cc: "H. Peter Anvin" <hpa@...or.come
Cc: Andy Lutomirski <luto@...nel.org>
Cc: Borislav Petkov <bp@...en8.de>
Link: https://lkml.kernel.org/r/20181012232118.3EAAE77B@viggo.jf.intel.com

---
 arch/x86/entry/entry_64.S | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 957dfb693ecc..1d9b4a300c8c 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1187,6 +1187,18 @@ ENTRY(paranoid_entry)
 	xorl	%ebx, %ebx
 
 1:
+	/*
+	 * Always stash CR3 in %r14.  This value will be restored,
+	 * verbatim, at exit.  Needed if kernel is interrupted
+	 * after switching to the user CR3 value but before
+	 * returning to userspace.
+	 *
+	 * This is also why CS (stashed in the "iret frame" by the
+	 * hardware at entry) can not be used: this may be a return
+	 * to kernel code, but with a user CR3 value.  The %ebx flag
+	 * for SWAPGS is also unusable for CR3 because there is a
+	 * window with a user GS and a kernel CR3.
+	 */
 	SAVE_AND_SWITCH_TO_KERNEL_CR3 scratch_reg=%rax save_reg=%r14
 
 	ret
@@ -1211,11 +1223,13 @@ ENTRY(paranoid_exit)
 	testl	%ebx, %ebx			/* swapgs needed? */
 	jnz	.Lparanoid_exit_no_swapgs
 	TRACE_IRQS_IRETQ
+	/* Always restore stashed CR3 value (see paranoid_entry) */
 	RESTORE_CR3	scratch_reg=%rbx save_reg=%r14
 	SWAPGS_UNSAFE_STACK
 	jmp	.Lparanoid_exit_restore
 .Lparanoid_exit_no_swapgs:
 	TRACE_IRQS_IRETQ_DEBUG
+	/* Always restore stashed CR3 value (see paranoid_entry) */
 	RESTORE_CR3	scratch_reg=%rbx save_reg=%r14
 .Lparanoid_exit_restore:
 	jmp restore_regs_and_return_to_kernel
@@ -1626,6 +1640,7 @@ end_repeat_nmi:
 	movq	$-1, %rsi
 	call	do_nmi
 
+	/* Always restore stashed CR3 value (see paranoid_entry) */
 	RESTORE_CR3 scratch_reg=%r15 save_reg=%r14
 
 	testl	%ebx, %ebx			/* swapgs needed? */