From: Peter Zijlstra <peterz@infradead.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
Yu-cheng Yu <yu-cheng.yu@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH 01/13] x86/fault: Check user_mode(regs) when avoiding an mmap_sem deadlock
Date: Tue, 20 Nov 2018 09:15:54 +0100 [thread overview]
Message-ID: <20181120081554.GD2131@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <4b89b542e8ceba9bd6abde2f386afed6d99244a9.1542667307.git.luto@kernel.org>
On Mon, Nov 19, 2018 at 02:45:25PM -0800, Andy Lutomirski wrote:
> The fault-handling code that takes mmap_sem needs to avoid a
> deadlock that could occur if the kernel took a bad (OOPS-worthy)
> page fault on a user address while holding mmap_sem. This can only
> happen if the faulting instruction was in the kernel
> (i.e. user_mode(regs)). Rather than checking the sw_error_code
!user_mode(regs), surely, as the patch actually does.
> (which will have the USER bit set if the fault was a USER-permission
> access *or* if user_mode(regs)), just check user_mode(regs)
> directly.
>
> The old code would have malfunctioned if the kernel executed a bogus
> WRUSS instruction while holding mmap_sem. Fortunately, that is
> extremely unlikely in current kernels, which don't use WRUSS.
>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
> ---
> arch/x86/mm/fault.c | 7 ++-----
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
> index 71d4b9d4d43f..91d4d2722f2e 100644
> --- a/arch/x86/mm/fault.c
> +++ b/arch/x86/mm/fault.c
> @@ -1344,13 +1344,10 @@ void do_user_addr_fault(struct pt_regs *regs,
> * Only do the expensive exception table search when we might be at
> * risk of a deadlock. This happens if we
> * 1. Failed to acquire mmap_sem, and
> - * 2. The access did not originate in userspace. Note: either the
> - * hardware or earlier page fault code may set X86_PF_USER
> - * in sw_error_code.
> + * 2. The access did not originate in userspace.
> */
> if (unlikely(!down_read_trylock(&mm->mmap_sem))) {
> - if (!(sw_error_code & X86_PF_USER) &&
> - !search_exception_tables(regs->ip)) {
> + if (!user_mode(regs) && !search_exception_tables(regs->ip)) {
> /*
> * Fault from code in kernel from
> * which we do not expect faults.
> --
> 2.17.2
>
next prev parent reply other threads:[~2018-11-20 8:16 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-19 22:45 [PATCH 00/13] x86/fault: #PF improvements, mostly related to USER bit Andy Lutomirski
2018-11-19 22:45 ` [PATCH 01/13] x86/fault: Check user_mode(regs) when avoiding an mmap_sem deadlock Andy Lutomirski
2018-11-20 8:14 ` [tip:x86/mm] " tip-bot for Andy Lutomirski
2018-11-20 8:15 ` Peter Zijlstra [this message]
2018-11-19 22:45 ` [PATCH 02/13] x86/fault: Check user_mode(regs) when validating a stack extension Andy Lutomirski
2018-11-20 7:39 ` Ingo Molnar
2018-11-20 8:13 ` Ingo Molnar
2018-11-19 22:45 ` [PATCH 03/13] x86/cpufeatures, x86/fault: Mark SMAP as disabled when configured out Andy Lutomirski
2018-11-20 8:15 ` [tip:x86/mm] " tip-bot for Andy Lutomirski
2018-11-19 22:45 ` [PATCH 04/13] x86/fault: Fold smap_violation() into do_user_addr_fault() Andy Lutomirski
2018-11-20 8:15 ` [tip:x86/mm] " tip-bot for Andy Lutomirski
2018-11-19 22:45 ` [PATCH 05/13] x86/fault: Fix SMAP #PF handling buglet for implicit supervisor accesses Andy Lutomirski
2018-11-20 8:16 ` [tip:x86/mm] " tip-bot for Andy Lutomirski
2018-11-19 22:45 ` [PATCH 06/13] x86/fault: Improve the condition for signalling vs OOPSing Andy Lutomirski
2018-11-20 8:16 ` [tip:x86/mm] " tip-bot for Andy Lutomirski
2018-11-19 22:45 ` [PATCH 07/13] x86/fault: Make error_code sanitization more robust Andy Lutomirski
2018-11-20 8:17 ` [tip:x86/mm] " tip-bot for Andy Lutomirski
2018-11-19 22:45 ` [PATCH 08/13] x86/fault: Don't set thread.cr2, etc before OOPSing Andy Lutomirski
2018-11-20 8:17 ` [tip:x86/mm] " tip-bot for Andy Lutomirski
2018-11-19 22:45 ` [PATCH 09/13] x86/fault: Remove sw_error_code Andy Lutomirski
2018-11-19 22:45 ` [PATCH 10/13] x86/fault: Don't try to recover from an implicit supervisor access Andy Lutomirski
2018-11-19 22:45 ` [PATCH 11/13] x86/oops: Show the correct CS value in show_regs() Andy Lutomirski
2018-11-19 22:45 ` [PATCH 12/13] x86/fault: Decode page fault OOPSes better Andy Lutomirski
2018-11-27 14:46 ` Sean Christopherson
2018-11-19 22:45 ` [PATCH 13/13] x86/vsyscall/64: Use X86_PF constants in the simulated #PF error code 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=20181120081554.GD2131@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=x86@kernel.org \
--cc=yu-cheng.yu@intel.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 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.