linux-kernel - Re: [RFC PATCH 7/7] arm64/efi: Call EFI runtime services without disabling preemption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250711134833.GI905792@noisy.programming.kicks-ass.net>
Date: Fri, 11 Jul 2025 15:48:33 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Ard Biesheuvel <ardb+git@...gle.com>
Cc: linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Ard Biesheuvel <ardb@...nel.org>, Will Deacon <will@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: [RFC PATCH 7/7] arm64/efi: Call EFI runtime services without
 disabling preemption

On Wed, May 14, 2025 at 07:43:47PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@...nel.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@...nel.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
>