linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jann Horn <jannh@google.com>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: kernel list <linux-kernel@vger.kernel.org>,
	sean.j.christopherson@intel.com,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	Andy Lutomirski <luto@kernel.org>
Subject: Re: [RFC][PATCH 7/8] x86/mm/vsyscall: consider vsyscall page part of user address space
Date: Sat, 8 Sep 2018 03:16:09 +0200	[thread overview]
Message-ID: <CAG48ez2e8yJJjHeKRTbu46=5mbssZo84iMinBx6B5BgziDJiVQ@mail.gmail.com> (raw)
In-Reply-To: <20180907194902.63F36CFE@viggo.jf.intel.com>

On Sat, Sep 8, 2018 at 2:28 AM Dave Hansen <dave.hansen@linux.intel.com> wrote:
> 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().
[...]
>  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;

I think something should check for "#ifdef CONFIG_X86_64"? 32-bit
doesn't have a vsyscall page, right? And this code probably shouldn't
veer off into the userspace-area fault handling code for addresses in
the range 0xff600000-0xff600fff... what is in that region on 32-bit?
Modules or something like that?
Maybe change is_vsyscall_vaddr() so that it always returns false on
32-bit, or put both the definition of is_vsyscall_vaddr() and this
code behind #ifdef guards.
And, in a separate patch, maybe also #ifdef-guard the definition of
VSYSCALL_ADDR in vsyscall.h? Nothing good is going to result from
making a garbage VSYSCALL_ADDR available to 32-bit code.

> +#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

"VMAse"? Is that a typo?

  parent reply	other threads:[~2018-09-08  1:17 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 ` [RFC][PATCH 7/8] x86/mm/vsyscall: consider vsyscall page part of user address space Dave Hansen
2018-09-07 22:58   ` Andy Lutomirski
2018-09-08  1:16   ` Jann Horn [this message]
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='CAG48ez2e8yJJjHeKRTbu46=5mbssZo84iMinBx6B5BgziDJiVQ@mail.gmail.com' \
    --to=jannh@google.com \
    --cc=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).