linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@linux.intel.com>
To: linux-kernel@vger.kernel.org
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	sean.j.christopherson@intel.com, peterz@infradead.org,
	tglx@linutronix.de, x86@kernel.org, luto@kernel.org
Subject: [RFC][PATCH 7/8] x86/mm/vsyscall: consider vsyscall page part of user address space
Date: Fri, 07 Sep 2018 12:49:02 -0700	[thread overview]
Message-ID: <20180907194902.63F36CFE@viggo.jf.intel.com> (raw)
In-Reply-To: <20180907194852.3C351B82@viggo.jf.intel.com>


From: Dave Hansen <dave.hansen@linux.intel.com>

The vsyscall page is weird.  It is in what is traditionally part of the
kernel address space.  But, it has user permissions and we handle faults
on it like we would on a user page: interrupts on.

Right now, we handle vsyscall emulation in the "bad_area" code, which
is used for both user-address-space and kernel-address-space faults.  Move
the handling to the user-address-space code *only* and ensure we get there
by "excluding" the vsyscall page from the kernel address space via a check
in fault_in_kernel_space().

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: x86@kernel.org
Cc: Andy Lutomirski <luto@kernel.org>
---

 b/arch/x86/mm/fault.c |   36 ++++++++++++++++++++++++------------
 1 file changed, 24 insertions(+), 12 deletions(-)

diff -puN arch/x86/mm/fault.c~vsyscall-is-user-address-space arch/x86/mm/fault.c
--- a/arch/x86/mm/fault.c~vsyscall-is-user-address-space	2018-09-07 11:21:48.720751896 -0700
+++ b/arch/x86/mm/fault.c	2018-09-07 11:21:48.724751896 -0700
@@ -873,18 +873,6 @@ __bad_area_nosemaphore(struct pt_regs *r
 		if (is_errata100(regs, address))
 			return;
 
-#ifdef CONFIG_X86_64
-		/*
-		 * Instruction fetch faults in the vsyscall page might need
-		 * emulation.
-		 */
-		if (unlikely((error_code & X86_PF_INSTR) &&
-			     is_vsyscall_vaddr(address))) {
-			if (emulate_vsyscall(regs, address))
-				return;
-		}
-#endif
-
 		/*
 		 * To avoid leaking information about the kernel page table
 		 * layout, pretend that user-mode accesses to kernel addresses
@@ -1192,6 +1180,13 @@ access_error(unsigned long error_code, s
 
 static int fault_in_kernel_space(unsigned long address)
 {
+	/*
+	 * The vsyscall page is at an address above TASK_SIZE_MAX,
+	 * but is not considered part of the kernel address space.
+	 */
+	if (is_vsyscall_vaddr(address))
+		return false;
+
 	return address >= TASK_SIZE_MAX;
 }
 
@@ -1357,6 +1352,23 @@ void do_user_addr_space_fault(struct pt_
 	if (sw_error_code & X86_PF_INSTR)
 		flags |= FAULT_FLAG_INSTRUCTION;
 
+#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.
+	 *
+	 * The vsyscall page does not have a "real" VMA, so do this
+	 * emulation before we go searching for VMAse
+	 */
+	if (unlikely((sw_error_code & X86_PF_INSTR) &&
+		     is_vsyscall_vaddr(address))) {
+		if (emulate_vsyscall(regs, address))
+			return;
+	}
+#endif
+
 	/*
 	 * Kernel-mode access to the user address space should only occur
 	 * inside well-defined areas of code listed in the exception
_

  parent reply	other threads:[~2018-09-07 19:51 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-07 19:48 [RFC][PATCH 0/8] x86/mm: page fault handling cleanups Dave Hansen
2018-09-07 19:48 ` [RFC][PATCH 1/8] x86/mm: clarify hardware vs. software "error_code" Dave Hansen
2018-09-07 22:48   ` Andy Lutomirski
2018-09-10 20:07     ` Dave Hansen
2018-09-10 21:17       ` Andy Lutomirski
2018-09-07 19:48 ` [RFC][PATCH 2/8] x86/mm: break out kernel address space handling Dave Hansen
2018-09-07 21:06   ` Sean Christopherson
2018-09-07 21:51     ` Dave Hansen
2018-09-07 22:21   ` Andy Lutomirski
2018-09-07 22:37     ` Dave Hansen
2018-09-07 19:48 ` [RFC][PATCH 3/8] x86/mm: break out user " Dave Hansen
2018-09-08  9:38   ` Peter Zijlstra
2018-09-10 20:20     ` Dave Hansen
2018-09-07 19:48 ` [RFC][PATCH 4/8] x86/mm: add clarifying comments for user addr space Dave Hansen
2018-09-07 19:49 ` [RFC][PATCH 5/8] x86/mm: fix exception table comments Dave Hansen
2018-09-07 21:04   ` Sean Christopherson
2018-09-07 21:51     ` Dave Hansen
2018-09-10 20:43       ` Sean Christopherson
2018-09-08  0:37   ` Jann Horn
2018-09-07 19:49 ` [RFC][PATCH 6/8] x86/mm: add vsyscall address helper Dave Hansen
2018-09-08  0:46   ` Jann Horn
2018-09-07 19:49 ` Dave Hansen [this message]
2018-09-07 22:58   ` [RFC][PATCH 7/8] x86/mm/vsyscall: consider vsyscall page part of user address space Andy Lutomirski
2018-09-08  1:16   ` Jann Horn
2018-09-07 19:49 ` [RFC][PATCH 8/8] x86/mm: remove spurious fault pkey check Dave Hansen

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=20180907194902.63F36CFE@viggo.jf.intel.com \
    --to=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --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;
as well as URLs for NNTP newsgroup(s).