linux-kernel.vger.kernel.org archive mirror
 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>,
	stable@vger.kernel.org, Peter Zijlstra <peterz@infradead.org>,
	Christoph Hellwig <hch@lst.de>
Subject: [PATCH 01/11] x86/fault: Fix AMD erratum #91 errata fixup for user code
Date: Sun, 31 Jan 2021 09:24:32 -0800	[thread overview]
Message-ID: <7aaa6ff8d29faea5a9324a85e5ad6c41c654e9e0.1612113550.git.luto@kernel.org> (raw)
In-Reply-To: <cover.1612113550.git.luto@kernel.org>

The recent rework of probe_kernel_read() and its conversion to
get_kernel_nofault() inadvertently broke is_prefetch().  We were using
probe_kernel_read() as a sloppy "read user or kernel memory" helper, but it
doens't do that any more.  The new get_kernel_nofault() reads *kernel*
memory only, which completely broke is_prefetch() for user access.

Adjust the code to the the correct accessor based on access mode.  The
manual address bounds check is no longer necessary, since the accessor
helpers (get_user() / get_kernel_nofault()) do the right thing all by
themselves.  As a bonus, by using the correct accessor, we don't need the
open-coded address bounds check.

While we're at it, disable the workaround on all CPUs except AMD Family
0xF.  By my reading of the Revision Guide for AMD Athlon™ 64 and AMD
Opteron™ Processors, only family 0xF is affected.

Fixes: eab0c6089b68 ("maccess: unify the probe kernel arch hooks")
Cc: stable@vger.kernel.org
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
---
 arch/x86/mm/fault.c | 31 +++++++++++++++++++++----------
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 106b22d1d189..50dfdc71761e 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -54,7 +54,7 @@ kmmio_fault(struct pt_regs *regs, unsigned long addr)
  * 32-bit mode:
  *
  *   Sometimes AMD Athlon/Opteron CPUs report invalid exceptions on prefetch.
- *   Check that here and ignore it.
+ *   Check that here and ignore it.  This is AMD erratum #91.
  *
  * 64-bit mode:
  *
@@ -83,11 +83,7 @@ check_prefetch_opcode(struct pt_regs *regs, unsigned char *instr,
 #ifdef CONFIG_X86_64
 	case 0x40:
 		/*
-		 * In AMD64 long mode 0x40..0x4F are valid REX prefixes
-		 * Need to figure out under what instruction mode the
-		 * instruction was issued. Could check the LDT for lm,
-		 * but for now it's good enough to assume that long
-		 * mode only uses well known segments or kernel.
+		 * In 64-bit mode 0x40..0x4F are valid REX prefixes
 		 */
 		return (!user_mode(regs) || user_64bit_mode(regs));
 #endif
@@ -124,23 +120,38 @@ is_prefetch(struct pt_regs *regs, unsigned long error_code, unsigned long addr)
 	if (error_code & X86_PF_INSTR)
 		return 0;
 
+	if (likely(boot_cpu_data.x86_vendor != X86_VENDOR_AMD
+		   || boot_cpu_data.x86 != 0xf))
+		return 0;
+
 	instr = (void *)convert_ip_to_linear(current, regs);
 	max_instr = instr + 15;
 
-	if (user_mode(regs) && instr >= (unsigned char *)TASK_SIZE_MAX)
-		return 0;
+	/*
+	 * This code has historically always bailed out if IP points to a
+	 * not-present page (e.g. due to a race).  No one has ever
+	 * complained about this.
+	 */
+	pagefault_disable();
 
 	while (instr < max_instr) {
 		unsigned char opcode;
 
-		if (get_kernel_nofault(opcode, instr))
-			break;
+		if (user_mode(regs)) {
+			if (get_user(opcode, instr))
+				break;
+		} else {
+			if (get_kernel_nofault(opcode, instr))
+				break;
+		}
 
 		instr++;
 
 		if (!check_prefetch_opcode(regs, instr, opcode, &prefetch))
 			break;
 	}
+
+	pagefault_enable();
 	return prefetch;
 }
 
-- 
2.29.2


  reply	other threads:[~2021-01-31 20:00 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-31 17:24 [PATCH 00/11] x86/fault: Cleanups and robustifications Andy Lutomirski
2021-01-31 17:24 ` Andy Lutomirski [this message]
2021-02-01  9:05   ` [PATCH 01/11] x86/fault: Fix AMD erratum #91 errata fixup for user code Christoph Hellwig
2021-02-01 20:31   ` Borislav Petkov
2021-01-31 17:24 ` [PATCH 02/11] x86/fault: Fold mm_fault_error() into do_user_addr_fault() Andy Lutomirski
2021-01-31 17:24 ` [PATCH 03/11] x86/fault/32: Move is_f00f_bug() do do_kern_addr_fault() Andy Lutomirski
2021-02-03 14:44   ` Borislav Petkov
2021-01-31 17:24 ` [PATCH 04/11] x86/fault: Document the locking in the fault_signal_pending() path Andy Lutomirski
2021-01-31 17:24 ` [PATCH 05/11] x86/fault: Correct a few user vs kernel checks wrt WRUSS Andy Lutomirski
2021-02-03 15:48   ` Borislav Petkov
2021-01-31 17:24 ` [PATCH 06/11] x86/fault: Improve kernel-executing-user-memory handling Andy Lutomirski
2021-02-01  9:08   ` Christoph Hellwig
2021-02-02  1:00     ` Andy Lutomirski
2021-02-03 16:01       ` Borislav Petkov
2021-02-03 16:23   ` Borislav Petkov
2021-01-31 17:24 ` [PATCH 07/11] x86/fault: Split the OOPS code out from no_context() Andy Lutomirski
2021-02-03 18:56   ` Borislav Petkov
2021-02-03 19:29     ` Andy Lutomirski
2021-02-03 19:46       ` Borislav Petkov
2021-02-09 20:09     ` Andy Lutomirski
2021-01-31 17:24 ` [PATCH 08/11] x86/fault: Bypass no_context() for implicit kernel faults from usermode Andy Lutomirski
2021-01-31 17:24 ` [PATCH 09/11] x86/fault: Rename no_context() to kernelmode_fixup_or_oops() Andy Lutomirski
2021-02-01  9:14   ` Christoph Hellwig
2021-02-02  1:01     ` Andy Lutomirski
2021-02-03 19:39   ` Borislav Petkov
2021-02-03 19:53     ` Andy Lutomirski
2021-02-03 20:07       ` Borislav Petkov
2021-02-03 20:14         ` Andy Lutomirski
2021-02-03 20:25           ` Borislav Petkov
2021-01-31 17:24 ` [PATCH 10/11] x86/fault: Don't run fixups for SMAP violations Andy Lutomirski
2021-02-03 19:50   ` Borislav Petkov
2021-01-31 17:24 ` [PATCH 11/11] x86/fault: Don't look for extable entries for SMEP violations 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=7aaa6ff8d29faea5a9324a85e5ad6c41c654e9e0.1612113550.git.luto@kernel.org \
    --to=luto@kernel.org \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=hch@lst.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=peterz@infradead.org \
    --cc=stable@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).