[RFC PATCH] arm64/efi: use id mapping for Runtime Services

[Will Deacon]

On Wed, Aug 06, 2014 at 04:15:23PM +0100, Ard Biesheuvel wrote:
> On 6 August 2014 16:36, Will Deacon <will.deacon at arm.com> wrote:
> > On Thu, Jul 31, 2014 at 03:11:49PM +0100, Ard Biesheuvel wrote:
> >>  #define efi_call_virt(f, ...)                                                \
> >>  ({                                                                   \
> >> -     efi_##f##_t *__f = efi.systab->runtime->f;                      \
> >> +     efi_##f##_t *__f;                                               \
> >>       efi_status_t __s;                                               \
> >>                                                                       \
> >> -     kernel_neon_begin();                                            \
> >> +     kernel_neon_begin(); /* disables preemption */                  \
> >> +     switch_pgd(idmap_pg_dir, &init_mm);                             \
> >> +     __f =  efi.systab->runtime->f;                                  \
> >>       __s = __f(__VA_ARGS__);                                         \
> >> +     switch_pgd(current->active_mm->pgd, current->active_mm);        \
> >>       kernel_neon_end();                                              \
> >>       __s;                                                            \
> >>  })
> >
> > This scares the bejesus out of me, but I can't put my finger on exactly why.
> > I think it does what you intend and I can't break it myself, so it would be
> > really good if the EFI folks could confirm that this looks good to them.
> >
> 
> There is something similar in the x86 code (arch/x86/platform/efi/efi.c)
> """
>  * The new method does a pagetable switch in a preemption-safe manner
>  * so that we're in a different address space when calling a runtime
>  * function. For function arguments passing we do copy the PGDs of the
>  * kernel page table into ->trampoline_pgd prior to each call.
> """
> 
> How exactly this will turn out for arm64 (and ARM) is still under
> discussion, though. My position is that if you are going to switch
> pgd's anyway, why not just use the id mapping? And even if you feel it
> is mandatory to install a virtual address mapping into UEFI (which I
> think is /not/ the case), you could install an id mapping as well,
> which means all the related machinery still gets invoked.
> The alternative to using a TTBR0 mapping would be to reserve a slice
> of kernel virtual memory so that the Runtime Services are guaranteed
> to live at the same virtual address after a kexec, ideally the same
> region on 4k and 64k pages ...
> 
> We are planning to discuss this further at Linaro Connect next month.

Ok, thanks for the update. I'll hold off on this until you've discussed it
some more.

Cheers,

Will