On Tue, 11 Jun 2024 at 15:17, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > On Mon, Jun 10, 2024 at 2:24 PM Ard Biesheuvel <ardb+git@xxxxxxxxxx> wrote: > > > From: Ard Biesheuvel <ardb@xxxxxxxxxx> > > > > EFI runtime services are remapped into the lower 1 GiB of virtual > > address space at boot, so they are guaranteed to be able to co-exist > > with the kernel virtual mappings without the need to allocate space for > > them in the kernel's vmalloc region, which is rather small. > > > > This means those mappings are covered by TTBR0 when LPAE PAN is enabled, > > and so 'user' access must be enabled while such calls are in progress. > > > > To avoid the need to refactor the code that is shared between ARM, arm64 > > and other EFI architectures, fold this into efi_set_pgd(). Given that > > EFI runtime services are serialized and not pre-emptible, storing the > > flags into a global variable is reasonable here - efi_set_pgd() calls > > will always occur in pairs on a single CPU. > > > > Cc: Kees Cook <keescook@xxxxxxxxxxxx> > > Cc: Linus Walleij <linus.walleij@xxxxxxxxxx> > > Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx> > > Makes sense to me! Thanks for looking into this. > Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> > Thanks, I'll queue this up as a EFI fix. Note that I have to fix an error in the patch: CONFIG_ARM_TTBR0_PAN does not exist, it should be CONFIG_CPU_TTBR0_PAN (and don't ask me why it worked because it definitely did - probably forgot to do git commit --amend)
