From: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
To: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org
Cc: ricardo.neri@intel.com, matt@codeblueprint.co.uk,
Sai Praneeth <sai.praneeth.prakhya@intel.com>,
Al Stone <astone@redhat.com>, Borislav Petkov <bp@alien8.de>,
Ingo Molnar <mingo@kernel.org>, Andy Lutomirski <luto@kernel.org>,
Bhupesh Sharma <bhsharma@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [PATCH V4 3/3] x86/efi: Introduce EFI_PAGE_FAULT_HANDLER
Date: Thu, 6 Sep 2018 16:27:48 -0700 [thread overview]
Message-ID: <1536276468-28499-4-git-send-email-sai.praneeth.prakhya@intel.com> (raw)
In-Reply-To: <1536276468-28499-1-git-send-email-sai.praneeth.prakhya@intel.com>
From: Sai Praneeth <sai.praneeth.prakhya@intel.com>
There may exist some buggy UEFI firmware implementations that might
access efi regions other than EFI_RUNTIME_SERVICES_<CODE/DATA> even
after the kernel has assumed control of the platform. This violates UEFI
specification.
If selected, this debug option will print a warning message if the UEFI
firmware tries to access any memory region which it shouldn't. Along
with the warning, the efi page fault handler will also try to recover
from the page fault triggered by the firmware so that the machine
doesn't hang.
Suggested-by: Matt Fleming <matt@codeblueprint.co.uk>
Based-on-code-from: Ricardo Neri <ricardo.neri@intel.com>
Signed-off-by: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: Al Stone <astone@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Bhupesh Sharma <bhsharma@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/x86/Kconfig | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f1dbb4ee19d7..cc840710ae3e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1957,6 +1957,24 @@ config EFI_MIXED
If unsure, say N.
+config EFI_PAGE_FAULT_HANDLER
+ bool "EFI page fault handler support" if EXPERT
+ depends on EFI
+ help
+ Enable this debug feature so that the kernel can recover from page
+ faults caused by buggy firmware. Also,
+ 1. If the page fault is caused by efi_reset_system(), then the
+ platform is rebooted through BIOS.
+ 2. If the page fault is caused by any other efi runtime service,
+ then the kernel freezes efi_rts_wq (work queue that runs efi
+ runtime services) and schedules a new process. Also, it disables
+ EFI Runtime Services, so that it will never again call buggy
+ firmware.
+ Please see the UEFI specification for details on the expectations
+ of memory usage.
+
+ If unsure, say N.
+
config SECCOMP
def_bool y
prompt "Enable seccomp to safely compute untrusted bytecode"
--
2.7.4
next prev parent reply other threads:[~2018-09-06 23:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-06 23:27 [PATCH V4 0/3] Add efi page fault handler to recover from page Sai Praneeth Prakhya
2018-09-06 23:27 ` [PATCH V4 1/3] efi: Make efi_rts_work accessible to efi page fault handler Sai Praneeth Prakhya
2018-09-06 23:27 ` [PATCH V4 2/3] x86/efi: Add efi page fault handler to recover from page faults caused by the firmware Sai Praneeth Prakhya
2018-09-07 11:21 ` Peter Zijlstra
2018-09-07 18:29 ` Prakhya, Sai Praneeth
2018-09-06 23:27 ` Sai Praneeth Prakhya [this message]
2018-09-07 11:22 ` [PATCH V4 3/3] x86/efi: Introduce EFI_PAGE_FAULT_HANDLER Peter Zijlstra
2018-09-07 18:23 ` Prakhya, Sai Praneeth
2018-09-07 18:49 ` Bhupesh Sharma
2018-09-07 19:08 ` Prakhya, Sai Praneeth
2018-09-07 19:22 ` Thomas Gleixner
2018-09-07 19:55 ` Bhupesh Sharma
2018-09-07 20:13 ` Thomas Gleixner
2018-09-07 10:42 ` [PATCH V4 0/3] Add efi page fault handler to recover from page Ard Biesheuvel
2018-09-07 18:32 ` Prakhya, Sai Praneeth
2018-09-07 19:03 ` Bhupesh Sharma
2018-09-07 19:13 ` Prakhya, Sai Praneeth
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=1536276468-28499-4-git-send-email-sai.praneeth.prakhya@intel.com \
--to=sai.praneeth.prakhya@intel.com \
--cc=ard.biesheuvel@linaro.org \
--cc=astone@redhat.com \
--cc=bhsharma@redhat.com \
--cc=bp@alien8.de \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=matt@codeblueprint.co.uk \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=ricardo.neri@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
all inboxes | Powered by JetHome®