From: Andy Lutomirski <luto@kernel.org>
To: LKML <linux-kernel@vger.kernel.org>
Cc: x86@kernel.org, "Bae, Chang Seok" <chang.seok.bae@intel.com>,
Borislav Petkov <bp@alien8.de>,
Peter Zijlstra <peterz@infradead.org>,
Andy Lutomirski <luto@kernel.org>,
Vegard Nossum <vegard.nossum@oracle.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H . Peter Anvin" <hpa@zytor.com>,
Andi Kleen <ak@linux.intel.com>,
Ravi Shankar <ravi.v.shankar@intel.com>
Subject: [PATCH 3/3] x86/entry/64: Fix and clean up paranoid_exit
Date: Mon, 1 Jul 2019 20:43:21 -0700 [thread overview]
Message-ID: <59725ceb08977359489fbed979716949ad45f616.1562035429.git.luto@kernel.org> (raw)
In-Reply-To: <cover.1562035429.git.luto@kernel.org>
paranoid_exit needs to restore CR3 before GSBASE. Doing it in the
opposite order crashes if the exception came from a context with
user GSBASE and user CR3 -- RESTORE_CR3 cannot resture user CR3 if
run with user GSBASE. This results in infinitely recursing
exceptions if user code does SYSENTER with TF set if both FSGSBASE
and PTI are enabled.
The old code worked if user code just set TF without SYSENTER
because #DB from user mode is special cased in idtentry and
paranoid_exit doesn't run.
Fix it by cleaning up the spaghetti code. All that paranoid_exit
needs to do is to disable IRQs, handle IRQ tracing, then restore
CR3, and restore GSBASE. Simply do those actions in that order.
Fixes: 708078f65721 ("x86/entry/64: Handle FSGSBASE enabled paranoid entry/exit")
Reported-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Ravi Shankar <ravi.v.shankar@intel.com>
Cc: "Bae, Chang Seok" <chang.seok.bae@intel.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
arch/x86/entry/entry_64.S | 33 +++++++++++++++++----------------
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 54b1b0468b2b..670306f588bf 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1256,31 +1256,32 @@ END(paranoid_entry)
ENTRY(paranoid_exit)
UNWIND_HINT_REGS
DISABLE_INTERRUPTS(CLBR_ANY)
- TRACE_IRQS_OFF_DEBUG
- /* Handle GS depending on FSGSBASE availability */
- ALTERNATIVE "jmp .Lparanoid_exit_checkgs", "nop",X86_FEATURE_FSGSBASE
+ /*
+ * The order of operations is important. IRQ tracing requires
+ * kernel GSBASE and CR3. RESTORE_CR3 requires kernel GS base.
+ *
+ * NB to anyone to tries to optimize this code: this code does
+ * not execute at all for exceptions coming from user mode. Those
+ * exceptions go through error_exit instead.
+ */
+ TRACE_IRQS_IRETQ_DEBUG
+ RESTORE_CR3 scratch_reg=%rax save_reg=%r14
+
+ /* Handle the three GSBASE cases. */
+ ALTERNATIVE "jmp .Lparanoid_exit_checkgs", "", X86_FEATURE_FSGSBASE
/* With FSGSBASE enabled, unconditionally restore GSBASE */
wrgsbase %rbx
- jmp .Lparanoid_exit_no_swapgs;
+ jmp restore_regs_and_return_to_kernel
.Lparanoid_exit_checkgs:
/* On non-FSGSBASE systems, conditionally do SWAPGS */
testl %ebx, %ebx
- 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
+ jnz restore_regs_and_return_to_kernel
-.Lparanoid_exit_restore:
+ /* We are returning to a context with user GSBASE. */
+ SWAPGS_UNSAFE_STACK
jmp restore_regs_and_return_to_kernel
END(paranoid_exit)
--
2.21.0
next prev parent reply other threads:[~2019-07-02 3:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-02 3:43 [PATCH 0/3] FSGSBASE fix, test, and a semi-related cleanup Andy Lutomirski
2019-07-02 3:43 ` [PATCH 1/3] selftests/x86: Test SYSCALL and SYSENTER manually with TF set Andy Lutomirski
2019-07-02 6:49 ` [tip:x86/cpu] " tip-bot for Andy Lutomirski
2019-07-02 3:43 ` [PATCH 2/3] x86/entry/64: Don't compile ignore_sysret if 32-bit emulation is enabled Andy Lutomirski
2019-07-02 6:49 ` [tip:x86/cpu] " tip-bot for Andy Lutomirski
2019-07-02 3:43 ` Andy Lutomirski [this message]
2019-07-02 6:50 ` [tip:x86/cpu] x86/entry/64: Fix and clean up paranoid_exit tip-bot for Andy Lutomirski
2019-07-02 3:57 ` [PATCH 0/3] FSGSBASE fix, test, and a semi-related cleanup Andy Lutomirski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59725ceb08977359489fbed979716949ad45f616.1562035429.git.luto@kernel.org \
--to=luto@kernel.org \
--cc=ak@linux.intel.com \
--cc=bp@alien8.de \
--cc=chang.seok.bae@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=ravi.v.shankar@intel.com \
--cc=tglx@linutronix.de \
--cc=vegard.nossum@oracle.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®