All of lore.kernel.org
 help / color / mirror / Atom feed
From: tip-bot for Andy Lutomirski <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: keescook@chromium.org, tglx@linutronix.de, mingo@kernel.org,
	luto@kernel.org, fweimer@redhat.com,
	linux-kernel@vger.kernel.org, hpa@zytor.com, jannh@google.com
Subject: [tip:x86/entry] x86/vsyscall: Show something useful on a read fault
Date: Thu, 27 Jun 2019 15:14:36 -0700	[thread overview]
Message-ID: <tip-918ce325098a4eef99daad7b6796da33cebaf03a@git.kernel.org> (raw)
In-Reply-To: <8016afffe0eab497be32017ad7f6f7030dc3ba66.1561610354.git.luto@kernel.org>

Commit-ID:  918ce325098a4eef99daad7b6796da33cebaf03a
Gitweb:     https://git.kernel.org/tip/918ce325098a4eef99daad7b6796da33cebaf03a
Author:     Andy Lutomirski <luto@kernel.org>
AuthorDate: Wed, 26 Jun 2019 21:45:04 -0700
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Fri, 28 Jun 2019 00:04:39 +0200

x86/vsyscall: Show something useful on a read fault

Just segfaulting the application when it tries to read the vsyscall page in
xonly mode is not helpful for those who need to debug it.

Emit a hint.

Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Jann Horn <jannh@google.com>
Link: https://lkml.kernel.org/r/8016afffe0eab497be32017ad7f6f7030dc3ba66.1561610354.git.luto@kernel.org

---
 arch/x86/entry/vsyscall/vsyscall_64.c | 19 ++++++++++++++++++-
 arch/x86/include/asm/vsyscall.h       |  6 ++++--
 arch/x86/mm/fault.c                   | 11 +++++------
 3 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
index fedd7628f3a6..9c58ab807aeb 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -117,7 +117,8 @@ static bool write_ok_or_segv(unsigned long ptr, size_t size)
 	}
 }
 
-bool emulate_vsyscall(struct pt_regs *regs, unsigned long address)
+bool emulate_vsyscall(unsigned long error_code,
+		      struct pt_regs *regs, unsigned long address)
 {
 	struct task_struct *tsk;
 	unsigned long caller;
@@ -126,6 +127,22 @@ bool emulate_vsyscall(struct pt_regs *regs, unsigned long address)
 	long ret;
 	unsigned long orig_dx;
 
+	/* Write faults or kernel-privilege faults never get fixed up. */
+	if ((error_code & (X86_PF_WRITE | X86_PF_USER)) != X86_PF_USER)
+		return false;
+
+	if (!(error_code & X86_PF_INSTR)) {
+		/* Failed vsyscall read */
+		if (vsyscall_mode == EMULATE)
+			return false;
+
+		/*
+		 * User code tried and failed to read the vsyscall page.
+		 */
+		warn_bad_vsyscall(KERN_INFO, regs, "vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround");
+		return false;
+	}
+
 	/*
 	 * No point in checking CS -- the only way to get here is a user mode
 	 * trap to a high address, which means that we're in 64-bit user code.
diff --git a/arch/x86/include/asm/vsyscall.h b/arch/x86/include/asm/vsyscall.h
index b986b2ca688a..ab60a71a8dcb 100644
--- a/arch/x86/include/asm/vsyscall.h
+++ b/arch/x86/include/asm/vsyscall.h
@@ -13,10 +13,12 @@ extern void set_vsyscall_pgtable_user_bits(pgd_t *root);
  * Called on instruction fetch fault in vsyscall page.
  * Returns true if handled.
  */
-extern bool emulate_vsyscall(struct pt_regs *regs, unsigned long address);
+extern bool emulate_vsyscall(unsigned long error_code,
+			     struct pt_regs *regs, unsigned long address);
 #else
 static inline void map_vsyscall(void) {}
-static inline bool emulate_vsyscall(struct pt_regs *regs, unsigned long address)
+static inline bool emulate_vsyscall(unsigned long error_code,
+				    struct pt_regs *regs, unsigned long address)
 {
 	return false;
 }
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 46df4c6aae46..288a5462076f 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1369,16 +1369,15 @@ void do_user_addr_fault(struct pt_regs *regs,
 
 #ifdef CONFIG_X86_64
 	/*
-	 * Instruction fetch faults in the vsyscall page might need
-	 * emulation.  The vsyscall page is at a high address
-	 * (>PAGE_OFFSET), but is considered to be part of the user
-	 * address space.
+	 * Faults in the vsyscall page might need emulation.  The
+	 * vsyscall page is at a high address (>PAGE_OFFSET), but is
+	 * considered to be part of the user address space.
 	 *
 	 * The vsyscall page does not have a "real" VMA, so do this
 	 * emulation before we go searching for VMAs.
 	 */
-	if ((hw_error_code & X86_PF_INSTR) && is_vsyscall_vaddr(address)) {
-		if (emulate_vsyscall(regs, address))
+	if (is_vsyscall_vaddr(address)) {
+		if (emulate_vsyscall(hw_error_code, regs, address))
 			return;
 	}
 #endif

  parent reply	other threads:[~2019-06-27 22:14 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-27  4:45 [PATCH v2 0/8] vsyscall xonly mode Andy Lutomirski
2019-06-27  4:45 ` [PATCH v2 1/8] x86/vsyscall: Remove the vsyscall=native documentation Andy Lutomirski
2019-06-27 17:26   ` Kees Cook
2019-06-27 22:13   ` [tip:x86/entry] Documentation/admin: " tip-bot for Andy Lutomirski
2019-06-27  4:45 ` [PATCH v2 2/8] x86/vsyscall: Add a new vsyscall=xonly mode Andy Lutomirski
2019-06-27 17:26   ` Kees Cook
2019-06-27 22:13   ` [tip:x86/entry] " tip-bot for Andy Lutomirski
2019-06-27  4:45 ` [PATCH v2 3/8] x86/vsyscall: Show something useful on a read fault Andy Lutomirski
2019-06-27 17:28   ` Kees Cook
2019-06-27 22:14   ` tip-bot for Andy Lutomirski [this message]
2019-06-27  4:45 ` [PATCH v2 4/8] x86/vsyscall: Document odd SIGSEGV error code for vsyscalls Andy Lutomirski
2019-06-27 17:28   ` Kees Cook
2019-06-27 22:15   ` [tip:x86/entry] " tip-bot for Andy Lutomirski
2019-06-27  4:45 ` [PATCH v2 5/8] selftests/x86/vsyscall: Verify that vsyscall=none blocks execution Andy Lutomirski
2019-06-27 17:29   ` Kees Cook
2019-06-27 22:16   ` [tip:x86/entry] " tip-bot for Andy Lutomirski
2019-06-27  4:45 ` [PATCH v2 6/8] x86/vsyscall: Change the default vsyscall mode to xonly Andy Lutomirski
2019-06-27 17:30   ` Kees Cook
2019-06-27 22:16   ` [tip:x86/entry] " tip-bot for Andy Lutomirski
2019-06-27  4:45 ` [PATCH v2 7/8] x86/vsyscall: Add __ro_after_init to global variables Andy Lutomirski
2019-06-27 17:30   ` Kees Cook
2019-06-27 22:17   ` [tip:x86/entry] " tip-bot for Andy Lutomirski
2019-06-27  4:45 ` [PATCH v2 8/8] selftests/x86: Add a test for process_vm_readv() on the vsyscall page Andy Lutomirski
2019-06-27 17:30   ` Kees Cook
2019-06-27 22:18   ` [tip:x86/entry] " tip-bot for 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=tip-918ce325098a4eef99daad7b6796da33cebaf03a@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=fweimer@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jannh@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    /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.