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: <CAMj1kXFLZWvEBTX__P6B+3nMn-HZpKaVRkiUmfj35xiG8LH0bQ@mail.gmail.com>
Date: Mon, 14 Jul 2025 16:38:57 +1000
From: Ard Biesheuvel <ardb@...nel.org>
To: Will Deacon <will@...nel.org>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-efi@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.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 Fri, 11 Jul 2025 at 23:42, Will Deacon <will@...nel.org> wrote:
>
> 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.
>

OK, I'll respin this to take that into account.