mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: x86@kernel.org
Cc: LKML <linux-kernel@vger.kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Yonghong Song <yhs@fb.com>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>
Subject: [PATCH v2 07/14] x86/fault: Improve kernel-executing-user-memory handling
Date: Tue,  9 Feb 2021 18:33:39 -0800	[thread overview]
Message-ID: <ab8719c7afb8bd501c4eee0e36493150fbbe5f6a.1612924255.git.luto@kernel.org> (raw)
In-Reply-To: <cover.1612924255.git.luto@kernel.org>

Right now we treat the case of the kernel trying to execute from user
memory more or less just like the kernel getting a page fault on a user
access.  In the failure path, we check for erratum #93, try to otherwise
fix up the error, and then oops.

If we manage to jump to the user address space, with or without SMEP, we
should not try to resolve the page fault.  This is an error, pure and
simple.  Rearrange the code so that we catch this case early, check for
erratum #93, and bail out.

Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
 arch/x86/mm/fault.c | 21 ++++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index b1104844260d..cbb1a9754473 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -447,6 +447,9 @@ static int is_errata93(struct pt_regs *regs, unsigned long address)
 	    || boot_cpu_data.x86 != 0xf)
 		return 0;
 
+	if (user_mode(regs))
+		return 0;
+
 	if (address != regs->ip)
 		return 0;
 
@@ -744,9 +747,6 @@ no_context(struct pt_regs *regs, unsigned long error_code,
 	if (is_prefetch(regs, error_code, address))
 		return;
 
-	if (is_errata93(regs, address))
-		return;
-
 	/*
 	 * Buggy firmware could access regions which might page fault, try to
 	 * recover from such faults.
@@ -1239,6 +1239,21 @@ void do_user_addr_fault(struct pt_regs *regs,
 	tsk = current;
 	mm = tsk->mm;
 
+	if (unlikely((error_code & (X86_PF_USER | X86_PF_INSTR)) == X86_PF_INSTR)) {
+		/*
+		 * Whoops, this is kernel mode code trying to execute from
+		 * user memory.  Unless this is AMD erratum #93, which
+		 * corrupts RIP such that it looks like a user address,
+		 * this is unrecoverable.  Don't even try to look up the
+		 * VMA.
+		 */
+		if (is_errata93(regs, address))
+			return;
+
+		bad_area_nosemaphore(regs, error_code, address);
+		return;
+	}
+
 	/* kprobes don't want to hook the spurious faults: */
 	if (unlikely(kprobe_page_fault(regs, X86_TRAP_PF)))
 		return;
-- 
2.29.2


  parent reply	other threads:[~2021-02-10  2:39 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-10  2:33 [PATCH v2 00/14] x86/fault: #PF improvements, mostly related to USER bit Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 01/14] x86/fault: Fix AMD erratum #91 errata fixup for user code Andy Lutomirski
2021-02-10  7:34   ` Christoph Hellwig
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 02/14] x86/fault: Skip the AMD erratum #91 workaround on unaffected CPUs Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 03/14] x86/fault: Fold mm_fault_error() into do_user_addr_fault() Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 04/14] x86/fault/32: Move is_f00f_bug() to do_kern_addr_fault() Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 05/14] x86/fault: Document the locking in the fault_signal_pending() path Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 06/14] x86/fault: Correct a few user vs kernel checks wrt WRUSS Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` Andy Lutomirski [this message]
2021-02-10 17:45   ` [tip: x86/mm] x86/fault: Improve kernel-executing-user-memory handling tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 08/14] x86/fault: Skip erratum #93 workaround on new CPUs Andy Lutomirski
2021-02-10  6:06   ` Andy Lutomirski
2021-02-10 13:29     ` Borislav Petkov
2021-02-10 16:09       ` Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 09/14] x86/fault: Split the OOPS code out from no_context() Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 10/14] x86/fault: Bypass no_context() for implicit kernel faults from usermode Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 11/14] x86/fault: Rename no_context() to kernelmode_fixup_or_oops() Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 12/14] x86/fault: Don't look for extable entries for SMEP violations Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 13/14] x86/fault: Don't run fixups for SMAP violations Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 14/14] x86/fault, x86/efi: Fix and rename efi_recover_from_page_fault() Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] x86/{fault,efi}: " tip-bot2 for Andy Lutomirski
2021-02-11  8:38   ` [PATCH v2 14/14] x86/fault, x86/efi: " Ard Biesheuvel
2021-02-10 13:57 ` [RFC][PATCH] kprobes: Remove kprobe::fault_handler Peter Zijlstra
2021-02-10 19:09   ` Christoph Hellwig
2021-02-10 19:47   ` Alexei Starovoitov

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=ab8719c7afb8bd501c4eee0e36493150fbbe5f6a.1612924255.git.luto@kernel.org \
    --to=luto@kernel.org \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=peterz@infradead.org \
    --cc=x86@kernel.org \
    --cc=yhs@fb.com \
    /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®