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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> Am 26.01.2019 um 13:28 schrieb Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>:
> 
>> On Sat, 26 Jan 2019 at 13:27, Heinrich Schuchardt <xypron.glpk@xxxxxx> wrote:
>> 
>>> On 1/26/19 11:22 AM, Ard Biesheuvel wrote:
>>> 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 native mapping used by the OS
>>> 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=efi, is likely to be useful
>>> to diagnose boot issues on such systems if they have no accessible serial
>>> port)
>>> 
>> 
>> NAK
>> 
> 
> Excuse me?
> 
>> This patch breaks EFI booting with any known U-Boot release.
>> 
> 
> It does if you pass 'efi=novmap'. Otherwise, it works fine.

Even then it doesn't break the entire boot, only runtime services (which are guarded anyway). I would claim that in most cases, we do not break even.

Alex





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux