[U-Boot] [PATCH] efi_loader: Patch non-runtime code out at ExitBootServices already

[Ard Biesheuvel]

On Fri, 25 Jan 2019 at 19:21, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 1/23/19 6:33 PM, Alexander Graf wrote:
> > While discussing something compeltely different, Ard pointed out
> > that it might be legal to omit calling SetVirtualAddressMap altogether.
> >
> > While that sounds great, we currently rely on that call to remove
> > all function pointers to code that we do not support outside of
> > boot services.
> >
> > So let's patch out those bits already on the call to ExitBootServices,
> > so that we can successfully run even when an OS chooses to omit
> > any call to SetVirtualAddressMap.
>
> Such an operating system would not be allowed to use any virtual
> addresses at any time because runtime drivers would not be informed
> about the mapping.
>

No. The OS would be permitted to invoke the runtime services at their
original offset.

For arm64, this is trivially achievable, since we already use userland
mappings for the runtime services. On 32-bit architectures, it is more
complicated, since the boot time mapping of peripherals and/or memory
may conflict with the kernel's layout of the address space (e.g., if
your NOR flash lives above 0xc0000000, you *have* to remap it for the
runtime services to be able to use it).



> Does such an operating system exist?
> Or is this only a hypothetical case?
>
> >
> > Reported-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> > Signed-off-by: Alexander Graf <agraf at suse.de>
>
> I am missing a description of the side effects of the change, e.g.
>
> Our EFI unit tests call the Reset() service.
>
> So Python tests will fail on systems that do not implement Reset() in a
> runtime compatible manner.
>

All runtime services (except SetVirtualAddresMap() and
ConvertPointer(), obviously) may be used at runtime with or without
installing a virtual address mapping.