All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-arch@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org, Dave Hansen <dave.hansen@linux.intel.com>
Subject: Re: [REVIEW][PATCH 17/20] signal/x86: Call force_sig_pkuerr from __bad_area_nosemaphore
Date: Tue, 18 Sep 2018 22:50:34 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.1809182249120.1468@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20180918000546.12552-17-ebiederm@xmission.com>

On Tue, 18 Sep 2018, Eric W. Biederman wrote:

> There is only one code path that can generate a pkuerr signal.  That
> code path calls __bad_area_nosemaphore and can be dectected by testing
> if si_code == SEGV_PKUERR.  It can be seen from inspection that all of
> the other tests in fill_sig_info_pkey are unnecessary.
> 
> Therefore call force_sig_pkuerr directly from __bad_area_semaphore
> and remove fill_sig_info_pkey.
> 
> At the same time move the comment above force_sig_info_pkey into
> bad_area_access_error, so that the documentation of about pkey

of about? Pick one please

> generation races is not lost.
> 
> Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
> ---
>  arch/x86/mm/fault.c | 75 ++++++++++++++-------------------------------
>  1 file changed, 23 insertions(+), 52 deletions(-)
> 
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 11a93f14a674..ccfeed902eee 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -153,56 +153,6 @@ is_prefetch(struct pt_regs *regs, unsigned long error_code, unsigned long addr)
>  	return prefetch;
>  }
>  
> -/*
> - * A protection key fault means that the PKRU value did not allow
> - * access to some PTE.  Userspace can figure out what PKRU was
> - * from the XSAVE state, and this function fills out a field in
> - * siginfo so userspace can discover which protection key was set
> - * on the PTE.
> - *
> - * If we get here, we know that the hardware signaled a X86_PF_PK
> - * fault and that there was a VMA once we got in the fault
> - * handler.  It does *not* guarantee that the VMA we find here
> - * was the one that we faulted on.
> - *
> - * 1. T1   : mprotect_key(foo, PAGE_SIZE, pkey=4);
> - * 2. T1   : set PKRU to deny access to pkey=4, touches page
> - * 3. T1   : faults...
> - * 4.    T2: mprotect_key(foo, PAGE_SIZE, pkey=5);
> - * 5. T1   : enters fault handler, takes mmap_sem, etc...
> - * 6. T1   : reaches here, sees vma_pkey(vma)=5, when we really
> - *	     faulted on a pte with its pkey=4.
> - */
> -static void fill_sig_info_pkey(int si_signo, int si_code, siginfo_t *info,
> -		u32 *pkey)
> -{
> -	/* This is effectively an #ifdef */
> -	if (!boot_cpu_has(X86_FEATURE_OSPKE))
> -		return;
> -
> -	/* Fault not from Protection Keys: nothing to do */
> -	if ((si_code != SEGV_PKUERR) || (si_signo != SIGSEGV))
> -		return;
> -	/*
> -	 * force_sig_info_fault() is called from a number of
> -	 * contexts, some of which have a VMA and some of which
> -	 * do not.  The X86_PF_PK handing happens after we have a
> -	 * valid VMA, so we should never reach this without a
> -	 * valid VMA.
> -	 */
> -	if (!pkey) {
> -		WARN_ONCE(1, "PKU fault with no VMA passed in");
> -		info->si_pkey = 0;
> -		return;
> -	}
> -	/*
> -	 * si_pkey should be thought of as a strong hint, but not
> -	 * absolutely guranteed to be 100% accurate because of
> -	 * the race explained above.
> -	 */
> -	info->si_pkey = *pkey;
> -}
> -
>  static void
>  force_sig_info_fault(int si_signo, int si_code, unsigned long address,
>  		     struct task_struct *tsk, u32 *pkey)
> @@ -215,8 +165,6 @@ force_sig_info_fault(int si_signo, int si_code, unsigned long address,
>  	info.si_code	= si_code;
>  	info.si_addr	= (void __user *)address;
>  
> -	fill_sig_info_pkey(si_signo, si_code, &info, pkey);
> -
>  	force_sig_info(si_signo, &info, tsk);
>  }
>  
> @@ -884,6 +832,9 @@ __bad_area_nosemaphore(struct pt_regs *regs, unsigned long error_code,
>  		tsk->thread.error_code	= error_code;
>  		tsk->thread.trap_nr	= X86_TRAP_PF;
>  
> +		if (si_code == SEGV_PKUERR)
> +			force_sig_pkuerr((void __user *)address, *pkey);
> +
>  		force_sig_info_fault(SIGSEGV, si_code, address, tsk, pkey);
>  
>  		return;
> @@ -949,6 +900,26 @@ bad_area_access_error(struct pt_regs *regs, unsigned long error_code,
>  	 * if pkeys are compiled out.
>  	 */
>  	if (bad_area_access_from_pkeys(error_code, vma)) {
> +		/*
> +		 * A protection key fault means that the PKRU value did not allow
> +		 * access to some PTE.  Userspace can figure out what PKRU was
> +		 * from the XSAVE state.  This function captures the pkey from
> +		 * the vma and passes it to userspace so userspace can discover
> +		 * which protection key was set on the PTE.
> +		 *
> +		 * If we get here, we know that the hardware signaled a X86_PF_PK
> +		 * fault and that there was a VMA once we got in the fault
> +		 * handler.  It does *not* guarantee that the VMA we find here
> +		 * was the one that we faulted on.
> +		 *
> +		 * 1. T1   : mprotect_key(foo, PAGE_SIZE, pkey=4);
> +		 * 2. T1   : set PKRU to deny access to pkey=4, touches page
> +		 * 3. T1   : faults...
> +		 * 4.    T2: mprotect_key(foo, PAGE_SIZE, pkey=5);
> +		 * 5. T1   : enters fault handler, takes mmap_sem, etc...
> +		 * 6. T1   : reaches here, sees vma_pkey(vma)=5, when we really
> +		 *	     faulted on a pte with its pkey=4.
> +		 */
>  		u32 pkey = vma_pkey(vma);
>  		__bad_area(regs, error_code, address, &pkey, SEGV_PKUERR);

Newline between variable declaration and code please.

With that fixed:

Reviewed-by: Thomas Gleixner <tglx@linutronix.de>


  reply	other threads:[~2018-09-18 20:50 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-18  0:03 [REVIEW][PATCH 00/20] siginfo cleanups for x86 Eric W. Biederman
2018-09-18  0:03 ` Eric W. Biederman
2018-09-18  0:05 ` [REVIEW][PATCH 01/20] signal: Simplify tracehook_report_syscall_exit Eric W. Biederman
2018-09-18 20:15   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 02/20] signal/x86: Inline fill_sigtrap_info in it's only caller send_sigtrap Eric W. Biederman
2018-09-18 20:16   ` Thomas Gleixner
2018-09-19  5:46   ` Christoph Hellwig
2018-09-19  6:46     ` Eric W. Biederman
2018-09-18  0:05 ` [REVIEW][PATCH 03/20] signal/x86: Move MCE error reporting out of force_sig_info_fault Eric W. Biederman
2018-09-18 20:19   ` Thomas Gleixner
2018-09-19 13:49     ` Eric W. Biederman
2018-09-18  0:05 ` [REVIEW][PATCH 04/20] signal/x86: Use send_sig_mceerr as apropriate Eric W. Biederman
2018-09-18 20:21   ` Thomas Gleixner
2018-10-01 13:04     ` Paolo Bonzini
2018-09-18  0:05 ` [REVIEW][PATCH 05/20] signal/x86: In trace_mpx_bounds_register_exception add __user annotations Eric W. Biederman
2018-09-18 20:22   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 06/20] signal/x86: Move mpx siginfo generation into do_bounds Eric W. Biederman
2018-09-18 20:25   ` Thomas Gleixner
2018-09-19  5:48   ` Christoph Hellwig
2018-09-19 13:52     ` Eric W. Biederman
2018-09-18  0:05 ` [REVIEW][PATCH 07/20] signal/x86/traps: Factor out show_signal Eric W. Biederman
2018-09-18 20:28   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 08/20] signal/x86/traps: Move setting error_code and trap_nr into do_trap_no_signal Eric W. Biederman
2018-09-18 20:33   ` Thomas Gleixner
2018-09-18 20:37     ` Thomas Gleixner
2018-09-21 12:45     ` Eric W. Biederman
2018-09-21 13:39       ` Eric W. Biederman
2018-09-18  0:05 ` [REVIEW][PATCH 09/20] signal/x86/traps: Use force_sig_bnderr Eric W. Biederman
2018-09-18 20:34   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 10/20] signal/x86/traps: Use force_sig instead of open coding it Eric W. Biederman
2018-09-18 20:34   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 11/20] signal/x86/traps: Simplify trap generation Eric W. Biederman
2018-09-18 20:37   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 12/20] signal/x86: Remove pkey parameter from bad_area_nosemaphore Eric W. Biederman
2018-09-18 20:44   ` Thomas Gleixner
2018-09-19 16:33     ` Dave Hansen
2018-09-21 12:34       ` Eric W. Biederman
2018-09-18  0:05 ` [REVIEW][PATCH 13/20] signal/x86: Remove the pkey parameter from do_sigbus Eric W. Biederman
2018-09-18 20:45   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 14/20] signal/x86: Remove pkey parameter from mm_fault_error Eric W. Biederman
2018-09-18 20:46   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 15/20] signal/x86: Don't compute pkey in __do_page_fault Eric W. Biederman
2018-09-18 20:46   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 16/20] signal/x86: Pass pkey not vma into __bad_area Eric W. Biederman
2018-09-18 20:48   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 17/20] signal/x86: Call force_sig_pkuerr from __bad_area_nosemaphore Eric W. Biederman
2018-09-18 20:50   ` Thomas Gleixner [this message]
2018-09-18  0:05 ` [REVIEW][PATCH 18/20] signal/x86: Replace force_sig_info_fault with force_sig_fault Eric W. Biederman
2018-09-18 20:51   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 19/20] signal/x86: Pass pkey by value Eric W. Biederman
2018-09-18 20:52   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 20/20] signal/x86: Use force_sig_fault where appropriate Eric W. Biederman
2018-09-18 20:53   ` Thomas Gleixner
2018-09-18 20:55 ` [REVIEW][PATCH 00/20] siginfo cleanups for x86 Thomas Gleixner
2018-09-18 21:10   ` Eric W. Biederman

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=alpine.DEB.2.21.1809182249120.1468@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --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 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.