[PATCH] efi/arm/arm64: Allow SetVirtualAddressMap() to be omitted

[Paolo Pisati]

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?id=4e46c2a956215482418d7b315749fb1b6c6bc224

On Fri, Feb 22, 2019 at 11:09 AM Seth Forshee
<seth.forshee at canonical.com> wrote:
>
> On Wed, Feb 20, 2019 at 03:51:34PM +0100, Paolo Pisati wrote:
> > From: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> >
> > The UEFI spec revision 2.7 errata A section 8.4 has the following to
> > say about the virtual memory runtime services:
> >
> >   "This section contains function definitions for the virtual memory
> >   support that may be optionally used by an operating system at runtime.
> >   If an operating system chooses to make EFI runtime service calls in a
> >   virtual addressing mode instead of the flat physical mode, then the
> >   operating system must use the services in this section to switch the
> >   EFI runtime services from flat physical addressing to virtual
> >   addressing."
> >
> > So it is pretty clear that calling SetVirtualAddressMap() is entirely
> > optional, and so there is no point in doing so unless it achieves
> > anything useful for us.
> >
> > This is not the case for 64-bit ARM. The identity mapping used by the
> > firmware is arbitrarily converted into another permutation of userland
> > addresses (i.e., bits [63:48] cleared), and the runtime code could easily
> > deal with the original layout in exactly the same way as it deals with
> > the converted layout. However, due to constraints related to page size
> > differences if the OS is not running with 4k pages, and related to
> > systems that may expose the individual sections of PE/COFF runtime
> > modules as different memory regions, creating the virtual layout is a
> > bit fiddly, and requires us to sort the memory map and reason about
> > adjacent regions with identical memory types etc etc.
> >
> > So the obvious fix is to stop calling SetVirtualAddressMap() altogether
> > on arm64 systems. However, to avoid surprises, which are notoriously
> > hard to diagnose when it comes to OS<->firmware interactions, let's
> > start by making it an opt-out feature, and implement support for the
> > 'efi=novamap' kernel command line parameter on ARM and arm64 systems.
> >
> > ( Note that 32-bit ARM generally does require SetVirtualAddressMap() to be
> >   used, given that the physical memory map and the kernel virtual address
> >   map are not guaranteed to be non-overlapping like on arm64. However,
> >   having support for efi=novamap,noruntime on 32-bit ARM, combined with
> >   the recently proposed support for earlycon=efifb, is likely to be useful
> >   to diagnose boot issues on such systems if they have no accessible serial
> >   port. )
> >
> > Tested-by: Jeffrey Hugo <jhugo at codeaurora.org>
> > Tested-by: Bjorn Andersson <bjorn.andersson at linaro.org>
> > Tested-by: Lee Jones <lee.jones at linaro.org>
> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
> > Cc: AKASHI Takahiro <takahiro.akashi at linaro.org>
> > Cc: Alexander Graf <agraf at suse.de>
> > Cc: Borislav Petkov <bp at alien8.de>
> > Cc: Heinrich Schuchardt <xypron.glpk at gmx.de>
> > Cc: Leif Lindholm <leif.lindholm at linaro.org>
> > Cc: Linus Torvalds <torvalds at linux-foundation.org>
> > Cc: Matt Fleming <matt at codeblueprint.co.uk>
> > Cc: Peter Jones <pjones at redhat.com>
> > Cc: Peter Zijlstra <peterz at infradead.org>
> > Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya at intel.com>
> > Cc: Thomas Gleixner <tglx at linutronix.de>
> > Cc: linux-efi at vger.kernel.org
> > Link: http://lkml.kernel.org/r/20190202094119.13230-8-ard.biesheuvel@linaro.org
> > Signed-off-by: Ingo Molnar <mingo at kernel.org>
> > (cherry picked from commit 4e46c2a956215482418d7b315749fb1b6c6bc224)
>
> This commit doesn't appear to be in Linus' tree. Where did it come from?
>


-- 
bye,
p.