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.
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 | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 5d188c6c44d7..1c86a891f6d7 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>
@@ -176,7 +177,12 @@ bool arch_efi_call_virt_setup(void)
if (WARN_ON(down_trylock(&efi_rt_lock)))
return false;
- efi_virtmap_load();
+ if (preemptible() && (current->flags & PF_KTHREAD)) {
+ migrate_disable();
+ kthread_use_mm(&efi_mm);
+ } else {
+ efi_virtmap_load();
+ }
uaccess_ttbr0_enable();
post_ttbr_update_workaround();
__efi_fpsimd_begin();
@@ -186,7 +192,12 @@ bool arch_efi_call_virt_setup(void)
void arch_efi_call_virt_teardown(void)
{
__efi_fpsimd_end();
- efi_virtmap_unload();
+ if (preemptible() && (current->flags & PF_KTHREAD)) {
+ kthread_unuse_mm(&efi_mm);
+ migrate_enable();
+ } else {
+ efi_virtmap_unload();
+ }
uaccess_ttbr0_disable();
up(&efi_rt_lock);
}
--
2.49.0.1101.gccaa498523-googOn Wed, May 14, 2025 at 07:43:47PM +0200, Ard Biesheuvel wrote:
> 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.
>
> Note, though, that the firmware executes at the same privilege level as
> the kernel, and is therefore able to disable interrupts altogether.
Is the migrate_disable() strictly required, or just paranoia?
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
> arch/arm64/kernel/efi.c | 15 +++++++++++++--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index 5d188c6c44d7..1c86a891f6d7 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>
>
> @@ -176,7 +177,12 @@ bool arch_efi_call_virt_setup(void)
> if (WARN_ON(down_trylock(&efi_rt_lock)))
> return false;
>
> - efi_virtmap_load();
> + if (preemptible() && (current->flags & PF_KTHREAD)) {
> + migrate_disable();
> + kthread_use_mm(&efi_mm);
> + } else {
> + efi_virtmap_load();
> + }
> uaccess_ttbr0_enable();
> post_ttbr_update_workaround();
> __efi_fpsimd_begin();
> @@ -186,7 +192,12 @@ bool arch_efi_call_virt_setup(void)
> void arch_efi_call_virt_teardown(void)
> {
> __efi_fpsimd_end();
> - efi_virtmap_unload();
> + if (preemptible() && (current->flags & PF_KTHREAD)) {
> + kthread_unuse_mm(&efi_mm);
> + migrate_enable();
> + } else {
> + efi_virtmap_unload();
> + }
> uaccess_ttbr0_disable();
> up(&efi_rt_lock);
> }
> --
> 2.49.0.1101.gccaa498523-goog
>
On Fri, 11 Jul 2025 at 23:48, Peter Zijlstra <peterz@infradead.org> wrote: > > On Wed, May 14, 2025 at 07:43:47PM +0200, Ard Biesheuvel wrote: > > 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. > > > > Note, though, that the firmware executes at the same privilege level as > > the kernel, and is therefore able to disable interrupts altogether. > > Is the migrate_disable() strictly required, or just paranoia? > Runtime services might be polling the secure firmware for an async completion when they are interrupted, and so I don't think it is generally safe to assume that an interrupted EFI runtime service can be resumed on another CPU.
On Mon, Jul 14, 2025 at 12:20:30PM +1000, Ard Biesheuvel wrote: > On Fri, 11 Jul 2025 at 23:48, Peter Zijlstra <peterz@infradead.org> wrote: > > > > On Wed, May 14, 2025 at 07:43:47PM +0200, Ard Biesheuvel wrote: > > > 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. > > > > > > Note, though, that the firmware executes at the same privilege level as > > > the kernel, and is therefore able to disable interrupts altogether. > > > > Is the migrate_disable() strictly required, or just paranoia? > > > > Runtime services might be polling the secure firmware for an async > completion when they are interrupted, and so I don't think it is > generally safe to assume that an interrupted EFI runtime service can > be resumed on another CPU. Can we please get a comment with that migrate_disable() explaining this? Thanks!
On Mon, 14 Jul 2025 at 20:55, Peter Zijlstra <peterz@infradead.org> wrote: > > On Mon, Jul 14, 2025 at 12:20:30PM +1000, Ard Biesheuvel wrote: > > On Fri, 11 Jul 2025 at 23:48, Peter Zijlstra <peterz@infradead.org> wrote: ... > > > Is the migrate_disable() strictly required, or just paranoia? > > > > > > > Runtime services might be polling the secure firmware for an async > > completion when they are interrupted, and so I don't think it is > > generally safe to assume that an interrupted EFI runtime service can > > be resumed on another CPU. > > Can we please get a comment with that migrate_disable() explaining this? > Sure
© 2016 - 2026 Red Hat, Inc.