linux-kernel - Re: [RFC PATCH 6/7] arm64/efi: Move uaccess en/disable out of efi_set

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: <aHEUpiXt-pW7DBAN@willie-the-truck>
Date: Fri, 11 Jul 2025 14:41:58 +0100
From: Will Deacon <will@...nel.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>,
	Mark Rutland <mark.rutland@....com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC PATCH 6/7] arm64/efi: Move uaccess en/disable out of
 efi_set_pgd()

On Wed, May 14, 2025 at 07:43:46PM +0200, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@...nel.org>
> 
> efi_set_pgd() will no longer be called when invoking EFI runtime
> services via the efi_rts_wq work queue, but the uaccess en/disable are
> still needed when using PAN emulation using TTBR0 switching. So move
> these into the callers.
> 
> Signed-off-by: Ard Biesheuvel <ardb@...nel.org>
> ---
>  arch/arm64/include/asm/efi.h | 3 ---
>  arch/arm64/kernel/efi.c      | 3 +++
>  2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
> index decf87777f57..abe9176a3a23 100644
> --- a/arch/arm64/include/asm/efi.h
> +++ b/arch/arm64/include/asm/efi.h
> @@ -132,15 +132,12 @@ static inline void efi_set_pgd(struct mm_struct *mm)
>  			 * exception when invoking the EFI run-time services.
>  			 */
>  			update_saved_ttbr0(current, mm);
> -			uaccess_ttbr0_enable();
> -			post_ttbr_update_workaround();
>  		} else {
>  			/*
>  			 * Defer the switch to the current thread's TTBR0_EL1
>  			 * until uaccess_enable(). Restore the current
>  			 * thread's saved ttbr0 corresponding to its active_mm
>  			 */
> -			uaccess_ttbr0_disable();
>  			update_saved_ttbr0(current, current->active_mm);
>  		}
>  	}
> diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
> index d01ae156bb63..5d188c6c44d7 100644
> --- a/arch/arm64/kernel/efi.c
> +++ b/arch/arm64/kernel/efi.c
> @@ -177,6 +177,8 @@ bool arch_efi_call_virt_setup(void)
>  		return false;
>  
>  	efi_virtmap_load();
> +	uaccess_ttbr0_enable();
> +	post_ttbr_update_workaround();
>  	__efi_fpsimd_begin();
>  	return true;
>  }
> @@ -185,6 +187,7 @@ void arch_efi_call_virt_teardown(void)
>  {
>  	__efi_fpsimd_end();
>  	efi_virtmap_unload();
> +	uaccess_ttbr0_disable();

Moving this after updating the saved TTBR0 isn't great for SWPAN, as it
means that if we take an exception (e.g. an IRQ) before calling
uaccess_ttbr0_disable() then I think we'll end up running with the user
page-table installed briefly in TTBR0 which SWPAN is supposed to prevent
outside of genuine uaccess sections.

Will