All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H . Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Borislav Petkov <bp@alien8.de>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: [PATCH 15/21] x86/espfix/64: Stop assuming that pt_regs is on the entry stack
Date: Mon, 27 Nov 2017 11:45:23 +0100	[thread overview]
Message-ID: <20171127104529.12435-16-mingo@kernel.org> (raw)
In-Reply-To: <20171127104529.12435-1-mingo@kernel.org>

From: Andy Lutomirski <luto@kernel.org>

When we start using an entry trampoline, a #GP from userspace will
be delivered on the entry stack, not on the task stack.  Fix the
espfix64 #DF fixup to set up #GP according to TSS.SP0, rather than
assuming that pt_regs + 1 == SP0.  This won't change anything
without an entry stack, but it will make the code continue to work
when an entry stack is added.

While we're at it, improve the comments to explain what's actually
going on.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Link: https://lkml.kernel.org/r/b1ef4136616c6bd2a75d1fd2736d1d54437d65a8.1511497875.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
 arch/x86/kernel/traps.c | 37 ++++++++++++++++++++++++++++---------
 1 file changed, 28 insertions(+), 9 deletions(-)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 2008dd0f8ccb..7d74d84896c6 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -349,9 +349,15 @@ dotraplinkage void do_double_fault(struct pt_regs *regs, long error_code)
 
 	/*
 	 * If IRET takes a non-IST fault on the espfix64 stack, then we
-	 * end up promoting it to a doublefault.  In that case, modify
-	 * the stack to make it look like we just entered the #GP
-	 * handler from user space, similar to bad_iret.
+	 * end up promoting it to a doublefault.  In that case, take
+	 * advantage of the fact that we're not using the normal (TSS.sp0)
+	 * stack right now.  We can write a fake #GP(0) frame at TSS.sp0
+	 * and then modify our own IRET frame so that, when we return,
+	 * we land directly at the #GP(0) vector with the stack already
+	 * set up according to its expectations.
+	 *
+	 * The net result is that our #GP handler will think that we
+	 * entered from usermode with the bad user context.
 	 *
 	 * No need for ist_enter here because we don't use RCU.
 	 */
@@ -359,13 +365,26 @@ dotraplinkage void do_double_fault(struct pt_regs *regs, long error_code)
 		regs->cs == __KERNEL_CS &&
 		regs->ip == (unsigned long)native_irq_return_iret)
 	{
-		struct pt_regs *normal_regs = task_pt_regs(current);
+		struct pt_regs *gpregs = (struct pt_regs *)this_cpu_read(cpu_tss.x86_tss.sp0) - 1;
+
+		/*
+		 * regs->sp points to the failing IRET frame on the
+		 * ESPFIX64 stack.  Copy it to the entry stack.  This fills
+		 * in gpregs->ss through gpregs->ip.
+		 *
+		 */
+		memmove(&gpregs->ip, (void *)regs->sp, 5*8);
+		gpregs->orig_ax = 0;  /* Missing (lost) #GP error code */
 
-		/* Fake a #GP(0) from userspace. */
-		memmove(&normal_regs->ip, (void *)regs->sp, 5*8);
-		normal_regs->orig_ax = 0;  /* Missing (lost) #GP error code */
+		/*
+		 * Adjust our frame so that we return straight to the #GP
+		 * vector with the expected RSP value.  This is safe because
+		 * we won't enable interupts or schedule before we invoke
+		 * general_protection, so nothing will clobber the stack
+		 * frame we just set up.
+		 */
 		regs->ip = (unsigned long)general_protection;
-		regs->sp = (unsigned long)&normal_regs->orig_ax;
+		regs->sp = (unsigned long)&gpregs->orig_ax;
 
 		return;
 	}
@@ -390,7 +409,7 @@ dotraplinkage void do_double_fault(struct pt_regs *regs, long error_code)
 	 *
 	 *   Processors update CR2 whenever a page fault is detected. If a
 	 *   second page fault occurs while an earlier page fault is being
-	 *   deliv- ered, the faulting linear address of the second fault will
+	 *   delivered, the faulting linear address of the second fault will
 	 *   overwrite the contents of CR2 (replacing the previous
 	 *   address). These updates to CR2 occur even if the page fault
 	 *   results in a double fault or occurs during the delivery of a
-- 
2.14.1

  parent reply	other threads:[~2017-11-27 10:46 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-27 10:45 [PATCH 00/21] Preparatory patches for x86 KAISER support Ingo Molnar
2017-11-27 10:45 ` [PATCH 01/21] x86/unwinder/orc: Don't bail on stack overflow Ingo Molnar
2017-11-27 14:47   ` Borislav Petkov
2017-11-27 10:45 ` [PATCH 02/21] x86/unwinder: Handle stack overflows more gracefully Ingo Molnar
2017-11-27 17:36   ` Borislav Petkov
2017-11-28  4:55     ` Josh Poimboeuf
2017-11-27 10:45 ` [PATCH 03/21] x86/irq: Remove an old outdated comment about context tracking races Ingo Molnar
2017-11-27 10:45 ` [PATCH 04/21] x86/irq/64: Print the offending IP in the stack overflow warning Ingo Molnar
2017-11-27 10:45 ` [PATCH 05/21] x86/entry/64: Allocate and enable the SYSENTER stack Ingo Molnar
2017-11-27 10:45 ` [PATCH 06/21] x86/dumpstack: Add get_stack_info() support for " Ingo Molnar
2017-11-27 10:45 ` [PATCH 07/21] x86/entry/gdt: Put per-CPU GDT remaps in ascending order Ingo Molnar
2017-11-27 10:45 ` [PATCH 08/21] x86/mm/fixmap: Generalize the GDT fixmap mechanism, introduce 'struct cpu_entry_area' Ingo Molnar
2017-11-27 10:45 ` [PATCH 09/21] x86/kasan/64: Teach KASAN about the cpu_entry_area Ingo Molnar
2017-11-27 10:45 ` [PATCH 10/21] x86/entry: Fix assumptions that the HW TSS is at the beginning of cpu_tss Ingo Molnar
2017-11-27 10:45 ` [PATCH 11/21] x86/dumpstack: Handle stack overflow on all stacks Ingo Molnar
2017-11-27 19:26   ` Linus Torvalds
2017-11-28  4:29     ` Josh Poimboeuf
2017-11-28  5:29       ` Andy Lutomirski
2017-11-28 18:15         ` Josh Poimboeuf
2017-11-27 10:45 ` [PATCH 12/21] x86/entry: Move SYSENTER_stack to the beginning of struct tss_struct Ingo Molnar
2017-11-27 10:45 ` [PATCH 13/21] x86/entry: Remap the TSS into the CPU entry area Ingo Molnar
2017-11-27 10:45 ` [PATCH 14/21] x86/entry/64: Separate cpu_current_top_of_stack from TSS.sp0 Ingo Molnar
2017-11-27 10:45 ` Ingo Molnar [this message]
2017-11-27 10:45 ` [PATCH 16/21] x86/entry/64: Use a per-CPU trampoline stack for IDT entries Ingo Molnar
2017-12-01 17:06   ` Dave Hansen
2017-12-01 17:44     ` Andy Lutomirski
2017-12-01 21:21       ` Dave Hansen
2017-12-01 21:59         ` Andy Lutomirski
2017-12-02  6:41         ` Kevin Easton
2017-11-27 10:45 ` [PATCH 17/21] x86/entry/64: Return to userspace from the trampoline stack Ingo Molnar
2017-11-27 10:45 ` [PATCH 18/21] x86/entry/64: Create a per-CPU SYSCALL entry trampoline Ingo Molnar
2017-11-27 10:45 ` [PATCH 19/21] x86/entry/64: Move the IST stacks into 'struct cpu_entry_area' Ingo Molnar
2017-11-27 10:45 ` [PATCH 20/21] x86/entry/64: Remove the SYSENTER stack canary Ingo Molnar
2017-11-27 10:45 ` [PATCH 21/21] x86/entry: Clean up the SYSENTER_stack code Ingo Molnar
2017-12-01 17:59   ` Borislav Petkov

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=20171127104529.12435-16-mingo@kernel.org \
    --to=mingo@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.