From: Ard Biesheuvel <ardb+git@google.com>
To: linux-efi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Ard Biesheuvel <ardb@kernel.org>, Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Brown <broonie@kernel.org>
Subject: [PATCH v3 8/8] arm64/efi: Call EFI runtime services without disabling preemption
Date: Thu, 18 Sep 2025 12:30:19 +0200 [thread overview]
Message-ID: <20250918103010.2973462-18-ardb+git@google.com> (raw)
In-Reply-To: <20250918103010.2973462-10-ardb+git@google.com>
From: Ard Biesheuvel <ardb@kernel.org>
The only remaining reason why EFI runtime services are invoked with
preemption disabled is the fact that the mm is swapped out behind the
back of the context switching code.
The kernel no longer disables preemption in kernel_neon_begin().
Furthermore, the EFI spec is being clarified to explicitly state that
only baseline FP/SIMD is permitted in EFI runtime service
implementations, and so the existing kernel mode NEON context switching
code is sufficient to preserve and restore the execution context of an
in-progress EFI runtime service call.
Most EFI calls are made from the efi_rts_wq, which is serviced by a
kthread. As kthreads never return to user space, they usually don't have
an mm, and so we can use the existing infrastructure to swap in the
efi_mm while the EFI call is in progress. This is visible to the
scheduler, which will therefore reactivate the selected mm when
switching out the kthread and back in again.
Given that the EFI spec explicitly permits runtime services to be called
with interrupts enabled, firmware code is already required to tolerate
interruptions. So rather than disable preemption, disable only migration
so that EFI runtime services are less likely to cause scheduling delays.
To avoid potential issues where runtime services are interrupted while
polling the secure firmware for async completions, keep migration
disabled so that a runtime service invocation does not resume on a
different CPU from the one it was started on.
Note, though, that the firmware executes at the same privilege level as
the kernel, and is therefore able to disable interrupts altogether.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
arch/arm64/kernel/efi.c | 23 ++++++++++++++++++--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index a60444dcec68..9b1603a69b69 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -10,6 +10,7 @@
#include <linux/efi.h>
#include <linux/init.h>
#include <linux/kmemleak.h>
+#include <linux/kthread.h>
#include <linux/screen_info.h>
#include <linux/vmalloc.h>
@@ -181,7 +182,19 @@ bool arch_efi_call_virt_setup(void)
if (WARN_ON(!mutex_trylock(&efi_rt_lock)))
return false;
- efi_virtmap_load();
+ if (preemptible() && (current->flags & PF_KTHREAD)) {
+ /*
+ * Disable migration to ensure that a preempted EFI runtime
+ * service call will be resumed on the same CPU. This avoids
+ * potential issues with EFI runtime calls that are preempted
+ * while polling for an asynchronous completion of a secure
+ * firmware call, which may not permit the CPU to change.
+ */
+ migrate_disable();
+ kthread_use_mm(&efi_mm);
+ } else {
+ efi_virtmap_load();
+ }
/*
* Enable access to the valid TTBR0_EL1 and invoke the errata
@@ -207,7 +220,13 @@ void arch_efi_call_virt_teardown(void)
*/
uaccess_ttbr0_disable();
- efi_virtmap_unload();
+ if (preemptible() && (current->flags & PF_KTHREAD)) {
+ kthread_unuse_mm(&efi_mm);
+ migrate_enable();
+ } else {
+ efi_virtmap_unload();
+ }
+
mutex_unlock(&efi_rt_lock);
}
--
2.51.0.384.g4c02a37b29-goog
next prev parent reply other threads:[~2025-09-18 10:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-18 10:30 [PATCH v3 0/8] arm64: Make EFI calls preemptible Ard Biesheuvel
2025-09-18 10:30 ` [PATCH v3 1/8] efi: Add missing static initializer for efi_mm::cpus_allowed_lock Ard Biesheuvel
2025-09-18 10:30 ` [PATCH v3 2/8] efi/runtime: Return success/failure from arch_efi_call_virt_setup() Ard Biesheuvel
2025-09-18 10:30 ` [PATCH v3 3/8] efi/runtime: Deal with arch_efi_call_virt_setup() returning failure Ard Biesheuvel
2025-09-18 10:30 ` [PATCH v3 4/8] arm64/fpsimd: Permit kernel mode NEON with IRQs off Ard Biesheuvel
2025-09-19 11:33 ` Will Deacon
2025-09-18 10:30 ` [PATCH v3 5/8] arm64/fpsimd: Drop special handling for EFI runtime services Ard Biesheuvel
2025-09-18 11:57 ` Ard Biesheuvel
2025-09-18 13:10 ` Mark Brown
2025-09-22 6:55 ` Ard Biesheuvel
2025-09-18 10:30 ` [PATCH v3 6/8] arm64/efi: Use a mutex to protect the EFI stack and FP/SIMD state Ard Biesheuvel
2025-09-19 11:35 ` Will Deacon
2025-09-19 13:42 ` Ard Biesheuvel
2025-09-19 13:54 ` Will Deacon
2025-09-18 10:30 ` [PATCH v3 7/8] arm64/efi: Move uaccess en/disable out of efi_set_pgd() Ard Biesheuvel
2025-09-19 11:36 ` Will Deacon
2025-09-18 10:30 ` Ard Biesheuvel [this message]
2025-09-19 11:36 ` [PATCH v3 8/8] arm64/efi: Call EFI runtime services without disabling preemption Will Deacon
2025-09-18 11:33 ` [PATCH v3 0/8] arm64: Make EFI calls preemptible Ard Biesheuvel
2025-09-18 11:44 ` Will Deacon
2025-09-18 11:48 ` Ard Biesheuvel
2025-09-19 11:38 ` Will Deacon
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=20250918103010.2973462-18-ardb+git@google.com \
--to=ardb+git@google.com \
--cc=ardb@kernel.org \
--cc=bigeasy@linutronix.de \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.org \
--cc=will@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