From: Will Deacon <will@kernel.org>
To: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org, Will Deacon <will@kernel.org>,
Ard Biesheuvel <ardb@kernel.org>, Gus Bourg <gus@bourg.net>
Subject: [PATCH] arm64/efi: Avoid voluntary preemption with efi_mm installed
Date: Tue, 11 Aug 2026 15:04:29 +0100 [thread overview]
Message-ID: <20260811140430.22832-1-will@kernel.org> (raw)
Gus reports a bad kernel memory access when using software PAN
(CONFIG_ARM64_SW_TTBR0_PAN=y) on a machine with support for EFI runtime
services:
Unable to handle kernel access to user memory outside uaccess routines
at virtual address 00000000f322ff30
Mem abort info:
ESR = 0x0000000096000004
FSC = 0x04: level 0 translation fault
Internal error: Oops: 0000000096000004 [#1] SMP
Workqueue: efi_rts_wq efi_call_rts
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : efi_call_rts+0xd8/0x288
Call trace:
efi_call_rts+0xd8/0x288 (P)
process_one_work+0x178/0x4f8
worker_thread+0x194/0x328
This is because the fpsimd context management code called from
__efi_fpsimd_begin() can preempt voluntarily, returning later to the EFI
code with an incorrect value for TTBR0_EL1 thanks to the deferred mm
switching used by the software PAN implementation.
Since EFI runtime services cannot preempt voluntarily and because the
fpsimd switching code does not rely on the TTBR0_EL1 mappings, simply
reorder the fpsimd switch so that it occurs before we change the
page-table.
Cc: Ard Biesheuvel <ardb@kernel.org>
Reported-by: Gus Bourg <gus@bourg.net>
Tested-by: Gus Bourg <gus@bourg.net>
Fixes: a5baf582f4c0 ("arm64/efi: Call EFI runtime services without disabling preemption")
Link: https://lore.kernel.org/all/20260806000144.3388823-1-gus@bourg.net/
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kernel/efi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 30cd7f804398..0ec90fd1754e 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -184,6 +184,8 @@ void arch_efi_call_virt_setup(void)
efi_virtmap_load();
}
+ __efi_fpsimd_begin();
+
/*
* Enable access to the valid TTBR0_EL1 and invoke the errata
* workaround directly since there is no return from exception when
@@ -191,8 +193,6 @@ void arch_efi_call_virt_setup(void)
*/
uaccess_ttbr0_enable();
post_ttbr_update_workaround();
-
- __efi_fpsimd_begin();
}
void arch_efi_call_virt_teardown(void)
--
2.55.0.679.g6767b8d81c-goog
next reply other threads:[~2026-08-11 14:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 14:04 Will Deacon [this message]
2026-08-11 14:19 ` [PATCH] arm64/efi: Avoid voluntary preemption with efi_mm installed Ard Biesheuvel
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=20260811140430.22832-1-will@kernel.org \
--to=will@kernel.org \
--cc=ardb@kernel.org \
--cc=gus@bourg.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.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