From: Borislav Petkov <bp@alien8.de>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>,
x86@kernel.org, LKML <linux-kernel@vger.kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Yonghong Song <yhs@fb.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH 09/11] x86/fault: Rename no_context() to kernelmode_fixup_or_oops()
Date: Wed, 3 Feb 2021 21:07:29 +0100 [thread overview]
Message-ID: <20210203200729.GL13819@zn.tnic> (raw)
In-Reply-To: <88AA1DD6-615B-4049-B335-F2F40F85EF08@amacapital.net>
On Wed, Feb 03, 2021 at 11:53:03AM -0800, Andy Lutomirski wrote:
> I feel like that would be more obfuscated — then the function would
> return without fixing anything for usermode faults, return after
> fixing it for kernel mode faults, or oops.
You practically pretty much have it already with the WARN_ON_ONCE. And
you can make the thing return 1 to denote it was in user_mode() and 0
otherwise. IINMSO, something like this:
---
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 08f5f74cf989..2b86d541b181 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -692,11 +692,12 @@ page_fault_oops(struct pt_regs *regs, unsigned long error_code,
oops_end(flags, regs, sig);
}
-static noinline void
+static noinline int
kernelmode_fixup_or_oops(struct pt_regs *regs, unsigned long error_code,
unsigned long address, int signal, int si_code)
{
- WARN_ON_ONCE(user_mode(regs));
+ if (WARN_ON_ONCE(user_mode(regs)))
+ return 1;
/* Are we prepared to handle this kernel fault? */
if (fixup_exception(regs, X86_TRAP_PF, error_code, address)) {
@@ -706,7 +707,7 @@ kernelmode_fixup_or_oops(struct pt_regs *regs, unsigned long error_code,
* task context.
*/
if (in_interrupt())
- return;
+ return 0;
/*
* Per the above we're !in_interrupt(), aka. task context.
@@ -726,7 +727,7 @@ kernelmode_fixup_or_oops(struct pt_regs *regs, unsigned long error_code,
/*
* Barring that, we can do the fixup and be happy.
*/
- return;
+ return 0;
}
/*
@@ -734,9 +735,11 @@ kernelmode_fixup_or_oops(struct pt_regs *regs, unsigned long error_code,
* instruction.
*/
if (is_prefetch(regs, error_code, address))
- return;
+ return 0;
page_fault_oops(regs, error_code, address);
+
+ return 0;
}
/*
@@ -781,10 +784,8 @@ __bad_area_nosemaphore(struct pt_regs *regs, unsigned long error_code,
{
struct task_struct *tsk = current;
- if (!user_mode(regs)) {
- kernelmode_fixup_or_oops(regs, error_code, address, pkey, si_code);
+ if (!kernelmode_fixup_or_oops(regs, error_code, address, pkey, si_code))
return;
- }
if (!(error_code & X86_PF_USER)) {
/* Implicit user access to kernel memory -- just oops */
@@ -913,10 +914,8 @@ do_sigbus(struct pt_regs *regs, unsigned long error_code, unsigned long address,
vm_fault_t fault)
{
/* Kernel mode? Handle exceptions or die: */
- if (!user_mode(regs)) {
- kernelmode_fixup_or_oops(regs, error_code, address, SIGBUS, BUS_ADRERR);
+ if (!kernelmode_fixup_or_oops(regs, error_code, address, SIGBUS, BUS_ADRERR))
return;
- }
/* User-space => ok to do another page fault: */
if (is_prefetch(regs, error_code, address))
@@ -1378,10 +1377,8 @@ void do_user_addr_fault(struct pt_regs *regs,
* Quick path to respond to signals. The core mm code
* has unlocked the mm for us if we get here.
*/
- if (!user_mode(regs))
- kernelmode_fixup_or_oops(regs, error_code, address,
- SIGBUS, BUS_ADRERR);
- return;
+ if (!kernelmode_fixup_or_oops(regs, error_code, address, SIGBUS, BUS_ADRERR))
+ return;
}
/*
@@ -1399,18 +1396,15 @@ void do_user_addr_fault(struct pt_regs *regs,
if (likely(!(fault & VM_FAULT_ERROR)))
return;
- if (fatal_signal_pending(current) && !user_mode(regs)) {
- kernelmode_fixup_or_oops(regs, error_code, address, 0, 0);
- return;
+ if (fatal_signal_pending(current)) {
+ if (!kernelmode_fixup_or_oops(regs, error_code, address, 0, 0))
+ return;
}
if (fault & VM_FAULT_OOM) {
/* Kernel mode? Handle exceptions or die: */
- if (!user_mode(regs)) {
- kernelmode_fixup_or_oops(regs, error_code, address,
- SIGSEGV, SEGV_MAPERR);
+ if (!kernelmode_fixup_or_oops(regs, error_code, address, SIGSEGV, SEGV_MAPERR))
return;
- }
/*
* We ran out of memory, call the OOM killer, and return the
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2021-02-03 20:08 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-31 17:24 [PATCH 00/11] x86/fault: Cleanups and robustifications Andy Lutomirski
2021-01-31 17:24 ` [PATCH 01/11] x86/fault: Fix AMD erratum #91 errata fixup for user code Andy Lutomirski
2021-02-01 9:05 ` Christoph Hellwig
2021-02-01 20:31 ` Borislav Petkov
2021-01-31 17:24 ` [PATCH 02/11] x86/fault: Fold mm_fault_error() into do_user_addr_fault() Andy Lutomirski
2021-01-31 17:24 ` [PATCH 03/11] x86/fault/32: Move is_f00f_bug() do do_kern_addr_fault() Andy Lutomirski
2021-02-03 14:44 ` Borislav Petkov
2021-01-31 17:24 ` [PATCH 04/11] x86/fault: Document the locking in the fault_signal_pending() path Andy Lutomirski
2021-01-31 17:24 ` [PATCH 05/11] x86/fault: Correct a few user vs kernel checks wrt WRUSS Andy Lutomirski
2021-02-03 15:48 ` Borislav Petkov
2021-01-31 17:24 ` [PATCH 06/11] x86/fault: Improve kernel-executing-user-memory handling Andy Lutomirski
2021-02-01 9:08 ` Christoph Hellwig
2021-02-02 1:00 ` Andy Lutomirski
2021-02-03 16:01 ` Borislav Petkov
2021-02-03 16:23 ` Borislav Petkov
2021-01-31 17:24 ` [PATCH 07/11] x86/fault: Split the OOPS code out from no_context() Andy Lutomirski
2021-02-03 18:56 ` Borislav Petkov
2021-02-03 19:29 ` Andy Lutomirski
2021-02-03 19:46 ` Borislav Petkov
2021-02-09 20:09 ` Andy Lutomirski
2021-01-31 17:24 ` [PATCH 08/11] x86/fault: Bypass no_context() for implicit kernel faults from usermode Andy Lutomirski
2021-01-31 17:24 ` [PATCH 09/11] x86/fault: Rename no_context() to kernelmode_fixup_or_oops() Andy Lutomirski
2021-02-01 9:14 ` Christoph Hellwig
2021-02-02 1:01 ` Andy Lutomirski
2021-02-03 19:39 ` Borislav Petkov
2021-02-03 19:53 ` Andy Lutomirski
2021-02-03 20:07 ` Borislav Petkov [this message]
2021-02-03 20:14 ` Andy Lutomirski
2021-02-03 20:25 ` Borislav Petkov
2021-01-31 17:24 ` [PATCH 10/11] x86/fault: Don't run fixups for SMAP violations Andy Lutomirski
2021-02-03 19:50 ` Borislav Petkov
2021-01-31 17:24 ` [PATCH 11/11] x86/fault: Don't look for extable entries for SMEP violations 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=20210203200729.GL13819@zn.tnic \
--to=bp@alien8.de \
--cc=ast@kernel.org \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=mhiramat@kernel.org \
--cc=peterz@infradead.org \
--cc=x86@kernel.org \
--cc=yhs@fb.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.