linux-toradex.git/include/linux/efi.h, branch v5.6-rc7

efi: Fix handling of multiple efi_fake_mem= entries

2020-01-20T07:14:29+00:00

Dave noticed that when specifying multiple efi_fake_mem= entries only
the last entry was successfully being reflected in the efi memory map.
This is due to the fact that the efi_memmap_insert() is being called
multiple times, but on successive invocations the insertion should be
applied to the last new memmap rather than the original map at
efi_fake_memmap() entry.

Rework efi_fake_memmap() to install the new memory map after each
efi_fake_mem= entry is parsed.

This also fixes an issue in efi_fake_memmap() that caused it to litter
emtpy entries into the end of the efi memory map. An empty entry causes
efi_memmap_insert() to attempt more memmap splits / copies than
efi_memmap_split_count() accounted for when sizing the new map. When
that happens efi_memmap_insert() may overrun its allocation, and if you
are lucky will spill over to an unmapped page leading to crash
signature like the following rather than silent corruption:

    BUG: unable to handle page fault for address: ffffffffff281000
    [..]
    RIP: 0010:efi_memmap_insert+0x11d/0x191
    [..]
    Call Trace:
     ? bgrt_init+0xbe/0xbe
     ? efi_arch_mem_reserve+0x1cb/0x228
     ? acpi_parse_bgrt+0xa/0xd
     ? acpi_table_parse+0x86/0xb8
     ? acpi_boot_init+0x494/0x4e3
     ? acpi_parse_x2apic+0x87/0x87
     ? setup_acpi_sci+0xa2/0xa2
     ? setup_arch+0x8db/0x9e1
     ? start_kernel+0x6a/0x547
     ? secondary_startup_64+0xb6/0xc0

Commit af1648984828 "x86/efi: Update e820 with reserved EFI boot
services data to fix kexec breakage" introduced more occurrences where
efi_memmap_insert() is invoked after an efi_fake_mem= configuration has
been parsed. Previously the side effects of vestigial empty entries were
benign, but with commit af1648984828 that follow-on efi_memmap_insert()
invocation triggers efi_memmap_insert() overruns.

Reported-by: Dave Young 
Signed-off-by: Dan Williams 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Ingo Molnar 
Link: https://lore.kernel.org/r/20191231014630.GA24942@dhcp-128-65.nay.redhat.com
Link: https://lore.kernel.org/r/20200113172245.27925-14-ardb@kernel.org

efi: Add tracking for dynamically allocated memmaps

2020-01-20T07:14:29+00:00

In preparation for fixing efi_memmap_alloc() leaks, add support for
recording whether the memmap was dynamically allocated from slab,
memblock, or is the original physical memmap provided by the platform.

Given this tracking is established in efi_memmap_alloc() and needs to be
carried to efi_memmap_install(), use 'struct efi_memory_map_data' to
convey the flags.

Some small cleanups result from this reorganization, specifically the
removal of local variables for 'phys' and 'size' that are already
tracked in @data.

Signed-off-by: Dan Williams 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Ingo Molnar 
Link: https://lore.kernel.org/r/20200113172245.27925-12-ardb@kernel.org

efi: Add a flags parameter to efi_memory_map

2020-01-20T07:14:28+00:00

In preparation for garbage collecting dynamically allocated EFI memory
maps, where the allocation method of memblock vs slab needs to be
recalled, convert the existing 'late' flag into a 'flags' bitmask.

Arrange for the flag to be passed via 'struct efi_memory_map_data'. This
structure grows additional flags in follow-on changes.

Signed-off-by: Dan Williams 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Ingo Molnar 
Link: https://lore.kernel.org/r/20200113172245.27925-11-ardb@kernel.org

efi: Allow disabling PCI busmastering on bridges during boot

2020-01-10T17:55:04+00:00

Add an option to disable the busmaster bit in the control register on
all PCI bridges before calling ExitBootServices() and passing control
to the runtime kernel. System firmware may configure the IOMMU to prevent
malicious PCI devices from being able to attack the OS via DMA. However,
since firmware can't guarantee that the OS is IOMMU-aware, it will tear
down IOMMU configuration when ExitBootServices() is called. This leaves
a window between where a hostile device could still cause damage before
Linux configures the IOMMU again.

If CONFIG_EFI_DISABLE_PCI_DMA is enabled or "efi=disable_early_pci_dma"
is passed on the command line, the EFI stub will clear the busmaster bit
on all PCI bridges before ExitBootServices() is called. This will
prevent any malicious PCI devices from being able to perform DMA until
the kernel reenables busmastering after configuring the IOMMU.

This option may cause failures with some poorly behaved hardware and
should not be enabled without testing. The kernel commandline options
"efi=disable_early_pci_dma" or "efi=no_disable_early_pci_dma" may be
used to override the default. Note that PCI devices downstream from PCI
bridges are disconnected from their drivers first, using the UEFI
driver model API, so that DMA can be disabled safely at the bridge
level.

[ardb: disconnect PCI I/O handles first, as suggested by Arvind]

Co-developed-by: Matthew Garrett 
Signed-off-by: Matthew Garrett 
Signed-off-by: Ard Biesheuvel 
Cc: Andy Lutomirski 
Cc: Ard Biesheuvel 
Cc: Arvind Sankar 
Cc: Matthew Garrett 
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20200103113953.9571-18-ardb@kernel.org
Signed-off-by: Ingo Molnar

efi/x86: Drop two near identical versions of efi_runtime_init()

2020-01-10T17:55:03+00:00

The routines efi_runtime_init32() and efi_runtime_init64() are
almost indistinguishable, and the only relevant difference is
the offset in the runtime struct from where to obtain the physical
address of the SetVirtualAddressMap() routine.

However, this address is only used once, when installing the virtual
address map that the OS will use to invoke EFI runtime services, and
at the time of the call, we will necessarily be running with a 1:1
mapping, and so there is no need to do the map/unmap dance here to
retrieve the address. In fact, in the preceding changes to these users,
we stopped using the address recorded here entirely.

So let's just get rid of all this code since it no longer serves a
purpose. While at it, tweak the logic so that we handle unsupported
and disable EFI runtime services in the same way, and unmap the EFI
memory map in both cases.

Signed-off-by: Ard Biesheuvel 
Cc: Andy Lutomirski 
Cc: Ard Biesheuvel 
Cc: Arvind Sankar 
Cc: Matthew Garrett 
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20200103113953.9571-12-ardb@kernel.org
Signed-off-by: Ingo Molnar

efi/x86: Avoid redundant cast of EFI firmware service pointer

2020-01-10T17:55:02+00:00

All EFI firmware call prototypes have been annotated as __efiapi,
permitting us to attach attributes regarding the calling convention
by overriding __efiapi to an architecture specific value.

On 32-bit x86, EFI firmware calls use the plain calling convention
where all arguments are passed via the stack, and cleaned up by the
caller. Let's add this to the __efiapi definition so we no longer
need to cast the function pointers before invoking them.

Signed-off-by: Ard Biesheuvel 
Cc: Andy Lutomirski 
Cc: Ard Biesheuvel 
Cc: Arvind Sankar 
Cc: Matthew Garrett 
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20200103113953.9571-6-ardb@kernel.org
Signed-off-by: Ingo Molnar

efi/libstub: Remove 'sys_table_arg' from all function prototypes

2019-12-25T09:49:23+00:00

We have a helper efi_system_table() that gives us the address of the
EFI system table in memory, so there is no longer point in passing
it around from each function to the next.

Signed-off-by: Ard Biesheuvel 
Cc: Arvind Sankar 
Cc: Borislav Petkov 
Cc: James Morse 
Cc: Matt Fleming 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191224151025.32482-20-ardb@kernel.org
Signed-off-by: Ingo Molnar

efi/libstub: Drop sys_table_arg from printk routines

2019-12-25T09:49:22+00:00

As a first step towards getting rid of the need to pass around a function
parameter 'sys_table_arg' pointing to the EFI system table, remove the
references to it in the printing code, which is represents the majority
of the use cases.

Signed-off-by: Ard Biesheuvel 
Cc: Arvind Sankar 
Cc: Borislav Petkov 
Cc: James Morse 
Cc: Matt Fleming 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191224151025.32482-19-ardb@kernel.org
Signed-off-by: Ingo Molnar

efi/libstub: Avoid protocol wrapper for file I/O routines

2019-12-25T09:49:20+00:00

The EFI file I/O routines built on top of the file I/O firmware
services are incompatible with mixed mode, so there is no need
to obfuscate them by using protocol wrappers whose only purpose
is to hide the mixed mode handling. So let's switch to plain
indirect calls instead.

This also means we can drop the mixed_mode aliases from the various
types involved.

Signed-off-by: Ard Biesheuvel 
Cc: Arvind Sankar 
Cc: Borislav Petkov 
Cc: James Morse 
Cc: Matt Fleming 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191224151025.32482-15-ardb@kernel.org
Signed-off-by: Ingo Molnar

efi/libstub: Annotate firmware routines as __efiapi

2019-12-25T09:49:19+00:00

Annotate all the firmware routines (boot services, runtime services and
protocol methods) called in the boot context as __efiapi, and make
it expand to __attribute__((ms_abi)) on 64-bit x86. This allows us
to use the compiler to generate the calls into firmware that use the
MS calling convention instead of the SysV one.

Signed-off-by: Ard Biesheuvel 
Cc: Arvind Sankar 
Cc: Borislav Petkov 
Cc: James Morse 
Cc: Matt Fleming 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191224151025.32482-13-ardb@kernel.org
Signed-off-by: Ingo Molnar