linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "tip-bot2 for Andy Lutomirski" <tip-bot2@linutronix.de>
To: linux-tip-commits@vger.kernel.org
Cc: Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@suse.de>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: [tip: x86/mm] x86/{fault,efi}: Fix and rename efi_recover_from_page_fault()
Date: Wed, 10 Feb 2021 17:45:54 -0000	[thread overview]
Message-ID: <161297915421.23325.12410595112961336936.tip-bot2@tip-bot2> (raw)
In-Reply-To: <f43b1e80830dc78ed60ed8b0826f4f189254570c.1612924255.git.luto@kernel.org>

The following commit has been merged into the x86/mm branch of tip:

Commit-ID:     c46f52231e79af025e2c89e889d69ec20a4c024f
Gitweb:        https://git.kernel.org/tip/c46f52231e79af025e2c89e889d69ec20a4c024f
Author:        Andy Lutomirski <luto@kernel.org>
AuthorDate:    Tue, 09 Feb 2021 18:33:46 -08:00
Committer:     Borislav Petkov <bp@suse.de>
CommitterDate: Wed, 10 Feb 2021 18:39:23 +01:00

x86/{fault,efi}: Fix and rename efi_recover_from_page_fault()

efi_recover_from_page_fault() doesn't recover -- it does a special EFI
mini-oops.  Rename it to make it clear that it crashes.

While renaming it, I noticed a blatant bug: a page fault oops in a
different thread happening concurrently with an EFI runtime service call
would be misinterpreted as an EFI page fault.  Fix that.

This isn't quite exact. The situation could be improved by using a
special CS for calls into EFI.

 [ bp: Massage commit message and simplify in interrupt check. ]

Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/f43b1e80830dc78ed60ed8b0826f4f189254570c.1612924255.git.luto@kernel.org
---
 arch/x86/include/asm/efi.h     |  2 +-
 arch/x86/mm/fault.c            | 11 ++++++-----
 arch/x86/platform/efi/quirks.c | 16 ++++++++++++----
 3 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index c98f783..4b7706d 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -150,7 +150,7 @@ extern void __init efi_apply_memmap_quirks(void);
 extern int __init efi_reuse_config(u64 tables, int nr_tables);
 extern void efi_delete_dummy_variable(void);
 extern void efi_switch_mm(struct mm_struct *mm);
-extern void efi_recover_from_page_fault(unsigned long phys_addr);
+extern void efi_crash_gracefully_on_page_fault(unsigned long phys_addr);
 extern void efi_free_boot_services(void);
 
 /* kexec external ABI */
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 1c3054b..7b3a125 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -16,7 +16,7 @@
 #include <linux/prefetch.h>		/* prefetchw			*/
 #include <linux/context_tracking.h>	/* exception_enter(), ...	*/
 #include <linux/uaccess.h>		/* faulthandler_disabled()	*/
-#include <linux/efi.h>			/* efi_recover_from_page_fault()*/
+#include <linux/efi.h>			/* efi_crash_gracefully_on_page_fault()*/
 #include <linux/mm_types.h>
 
 #include <asm/cpufeature.h>		/* boot_cpu_has, ...		*/
@@ -25,7 +25,7 @@
 #include <asm/vsyscall.h>		/* emulate_vsyscall		*/
 #include <asm/vm86.h>			/* struct vm86			*/
 #include <asm/mmu_context.h>		/* vma_pkey()			*/
-#include <asm/efi.h>			/* efi_recover_from_page_fault()*/
+#include <asm/efi.h>			/* efi_crash_gracefully_on_page_fault()*/
 #include <asm/desc.h>			/* store_idt(), ...		*/
 #include <asm/cpu_entry_area.h>		/* exception stack		*/
 #include <asm/pgtable_areas.h>		/* VMALLOC_START, ...		*/
@@ -701,11 +701,12 @@ page_fault_oops(struct pt_regs *regs, unsigned long error_code,
 #endif
 
 	/*
-	 * Buggy firmware could access regions which might page fault, try to
-	 * recover from such faults.
+	 * Buggy firmware could access regions which might page fault.  If
+	 * this happens, EFI has a special OOPS path that will try to
+	 * avoid hanging the system.
 	 */
 	if (IS_ENABLED(CONFIG_EFI))
-		efi_recover_from_page_fault(address);
+		efi_crash_gracefully_on_page_fault(address);
 
 oops:
 	/*
diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
index 5a40fe4..67d93a2 100644
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -687,15 +687,25 @@ int efi_capsule_setup_info(struct capsule_info *cap_info, void *kbuff,
  * @return: Returns, if the page fault is not handled. This function
  * will never return if the page fault is handled successfully.
  */
-void efi_recover_from_page_fault(unsigned long phys_addr)
+void efi_crash_gracefully_on_page_fault(unsigned long phys_addr)
 {
 	if (!IS_ENABLED(CONFIG_X86_64))
 		return;
 
 	/*
+	 * If we get an interrupt/NMI while processing an EFI runtime service
+	 * then this is a regular OOPS, not an EFI failure.
+	 */
+	if (in_interrupt())
+		return;
+
+	/*
 	 * Make sure that an efi runtime service caused the page fault.
+	 * READ_ONCE() because we might be OOPSing in a different thread,
+	 * and we don't want to trip KTSAN while trying to OOPS.
 	 */
-	if (efi_rts_work.efi_rts_id == EFI_NONE)
+	if (READ_ONCE(efi_rts_work.efi_rts_id) == EFI_NONE ||
+	    current_work() != &efi_rts_work.work)
 		return;
 
 	/*
@@ -747,6 +757,4 @@ void efi_recover_from_page_fault(unsigned long phys_addr)
 		set_current_state(TASK_IDLE);
 		schedule();
 	}
-
-	return;
 }

  reply	other threads:[~2021-02-10 17:47 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-10  2:33 [PATCH v2 00/14] x86/fault: #PF improvements, mostly related to USER bit Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 01/14] x86/fault: Fix AMD erratum #91 errata fixup for user code Andy Lutomirski
2021-02-10  7:34   ` Christoph Hellwig
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 02/14] x86/fault: Skip the AMD erratum #91 workaround on unaffected CPUs Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 03/14] x86/fault: Fold mm_fault_error() into do_user_addr_fault() Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 04/14] x86/fault/32: Move is_f00f_bug() to do_kern_addr_fault() Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 05/14] x86/fault: Document the locking in the fault_signal_pending() path Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 06/14] x86/fault: Correct a few user vs kernel checks wrt WRUSS Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 07/14] x86/fault: Improve kernel-executing-user-memory handling Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 08/14] x86/fault: Skip erratum #93 workaround on new CPUs Andy Lutomirski
2021-02-10  6:06   ` Andy Lutomirski
2021-02-10 13:29     ` Borislav Petkov
2021-02-10 16:09       ` Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 09/14] x86/fault: Split the OOPS code out from no_context() Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 10/14] x86/fault: Bypass no_context() for implicit kernel faults from usermode Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 11/14] x86/fault: Rename no_context() to kernelmode_fixup_or_oops() Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 12/14] x86/fault: Don't look for extable entries for SMEP violations Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 13/14] x86/fault: Don't run fixups for SMAP violations Andy Lutomirski
2021-02-10 17:45   ` [tip: x86/mm] " tip-bot2 for Andy Lutomirski
2021-02-10  2:33 ` [PATCH v2 14/14] x86/fault, x86/efi: Fix and rename efi_recover_from_page_fault() Andy Lutomirski
2021-02-10 17:45   ` tip-bot2 for Andy Lutomirski [this message]
2021-02-11  8:38   ` Ard Biesheuvel
2021-02-10 13:57 ` [RFC][PATCH] kprobes: Remove kprobe::fault_handler Peter Zijlstra
2021-02-10 19:09   ` Christoph Hellwig
2021-02-10 19:47   ` Alexei Starovoitov

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=161297915421.23325.12410595112961336936.tip-bot2@tip-bot2 \
    --to=tip-bot2@linutronix.de \
    --cc=bp@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=luto@kernel.org \
    --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).