linux-toradex.git/arch/arm64/kernel/efi.c, branch v4.3.2

arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regions

2015-10-01T10:51:28+00:00

The new Properties Table feature introduced in UEFIv2.5 may
split memory regions that cover PE/COFF memory images into
separate code and data regions. Since these regions only differ
in the type (runtime code vs runtime data) and the permission
bits, but not in the memory type attributes (UC/WC/WT/WB), the
spec does not require them to be aligned to 64 KB.

Since the relative offset of PE/COFF .text and .data segments
cannot be changed on the fly, this means that we can no longer
pad out those regions to be mappable using 64 KB pages.
Unfortunately, there is no annotation in the UEFI memory map
that identifies data regions that were split off from a code
region, so we must apply this logic to all adjacent runtime
regions whose attributes only differ in the permission bits.

So instead of rounding each memory region to 64 KB alignment at
both ends, only round down regions that are not directly
preceded by another runtime region with the same type
attributes. Since the UEFI spec does not mandate that the memory
map be sorted, this means we also need to sort it first.

Note that this change will result in all EFI_MEMORY_RUNTIME
regions whose start addresses are not aligned to the OS page
size to be mapped with executable permissions (i.e., on kernels
compiled with 64 KB pages). However, since these mappings are
only active during the time that UEFI Runtime Services are being
invoked, the window for abuse is rather small.

Tested-by: Mark Salter 
Tested-by: Mark Rutland  [UEFI 2.4 only]
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Matt Fleming 
Reviewed-by: Mark Salter 
Reviewed-by: Mark Rutland 
Cc:  # v4.0+
Cc: Catalin Marinas 
Cc: Leif Lindholm 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Will Deacon 
Cc: linux-kernel@vger.kernel.org
Link: http://lkml.kernel.org/r/1443218539-7610-3-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar

arm64/efi: map the entire UEFI vendor string before reading it

2015-07-27T17:00:05+00:00

At boot, the UTF-16 UEFI vendor string is copied from the system
table into a char array with a size of 100 bytes. However, this
size of 100 bytes is also used for memremapping() the source,
which may not be sufficient if the vendor string exceeds 50
UTF-16 characters, and the placement of the vendor string inside
a 4 KB page happens to leave the end unmapped.

So use the correct '100 * sizeof(efi_char16_t)' for the size of
the mapping.

Signed-off-by: Ard Biesheuvel 
Fixes: f84d02755f5a ("arm64: add EFI runtime services")
Cc:  # 3.16+
Signed-off-by: Catalin Marinas

e820, efi: add ACPI 6.0 persistent memory types

2015-05-28T01:46:05+00:00

ACPI 6.0 formalizes e820-type-7 and efi-type-14 as persistent memory.
Mark it "reserved" and allow it to be claimed by a persistent memory
device driver.

This definition is in addition to the Linux kernel's existing type-12
definition that was recently added in support of shipping platforms with
NVDIMM support that predate ACPI 6.0 (which now classifies type-12 as
OEM reserved).

Note, /proc/iomem can be consulted for differentiating legacy
"Persistent Memory (legacy)" E820_PRAM vs standard "Persistent Memory"
E820_PMEM.

Cc: Boaz Harrosh 
Cc: Ingo Molnar 
Cc: Christoph Hellwig 
Cc: Andrew Morton 
Cc: Borislav Petkov 
Cc: H. Peter Anvin 
Cc: Jens Axboe 
Cc: Linus Torvalds 
Cc: Matthew Wilcox 
Cc: Thomas Gleixner 
Acked-by: Jeff Moyer 
Acked-by: Andy Lutomirski 
Reviewed-by: Ross Zwisler 
Acked-by: Christoph Hellwig 
Tested-by: Toshi Kani 
Signed-off-by: Dan Williams

arm64: efi: don't restore TTBR0 if active_mm points at init_mm

2015-03-20T17:05:16+00:00

init_mm isn't a normal mm: it has swapper_pg_dir as its pgd (which
contains kernel mappings) and is used as the active_mm for the idle
thread.

When restoring the pgd after an EFI call, we write current->active_mm
into TTBR0. If the current task is actually the idle thread (e.g. when
initialising the EFI RTC before entering userspace), then the TLB can
erroneously populate itself with junk global entries as a result of
speculative table walks.

When we do eventually return to userspace, the task can end up hitting
these junk mappings leading to lockups, corruption or crashes.

This patch fixes the problem in the same way as the CPU suspend code by
ensuring that we never switch to the init_mm in efi_set_pgd and instead
point TTBR0 at the zero page. A check is also added to cpu_switch_mm to
BUG if we get passed swapper_pg_dir.

Reviewed-by: Ard Biesheuvel 
Fixes: f3cdfd239da5 ("arm64/efi: move SetVirtualAddressMap() to UEFI stub")
Signed-off-by: Will Deacon 
Signed-off-by: Catalin Marinas

efi/arm64: use UEFI for system reset and poweroff

2015-03-14T11:00:18+00:00

If UEFI Runtime Services are available, they are preferred over direct
PSCI calls or other methods to reset the system.

For the reset case, we need to hook into machine_restart(), as the
arm_pm_restart function pointer may be overwritten by modules.

Tested-by: Mark Rutland 
Reviewed-by: Mark Rutland 
Reviewed-by: Matt Fleming 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Catalin Marinas

arm64/efi: move virtmap init to early initcall

2015-01-22T14:59:25+00:00

Now that the create_mapping() code in mm/mmu.c is able to support
setting up kernel page tables at initcall time, we can move the whole
virtmap creation to arm64_enable_runtime_services() instead of having
a distinct stage during early boot. This also allows us to drop the
arm64-specific EFI_VIRTMAP flag.

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Catalin Marinas

arm64/efi: handle potential failure to remap memory map

2015-01-16T16:18:16+00:00

When remapping the UEFI memory map using ioremap_cache(), we
have to deal with potential failure. Note that, even if the
common case is for ioremap_cache() to return the existing linear
mapping of the memory map, we cannot rely on that to be always the
case, e.g., in the presence of a mem= kernel parameter.

At the same time, remove a stale comment and move the memmap code
together.

Signed-off-by: Ard Biesheuvel 
Acked-by: Mark Rutland 
Acked-by: Mark Salter 
Signed-off-by: Catalin Marinas

arm64/efi: remove idmap manipulations from UEFI code

2015-01-12T16:29:32+00:00

Now that we have moved the call to SetVirtualAddressMap() to the stub,
UEFI has no use for the ID map, so we can drop the code that installs
ID mappings for UEFI memory regions.

Acked-by: Leif Lindholm 
Acked-by: Will Deacon 
Tested-by: Leif Lindholm 
Signed-off-by: Ard Biesheuvel

arm64/efi: remove free_boot_services() and friends

2015-01-12T16:29:31+00:00

Now that we are calling SetVirtualAddressMap() from the stub, there is no
need to reserve boot-only memory regions, which implies that there is also
no reason to free them again later.

Acked-by: Leif Lindholm 
Acked-by: Will Deacon 
Tested-by: Leif Lindholm 
Signed-off-by: Ard Biesheuvel

arm64/efi: move SetVirtualAddressMap() to UEFI stub

2015-01-12T16:29:12+00:00

In order to support kexec, the kernel needs to be able to deal with the
state of the UEFI firmware after SetVirtualAddressMap() has been called.
To avoid having separate code paths for non-kexec and kexec, let's move
the call to SetVirtualAddressMap() to the stub: this will guarantee us
that it will only be called once (since the stub is not executed during
kexec), and ensures that the UEFI state is identical between kexec and
normal boot.

This implies that the layout of the virtual mapping needs to be created
by the stub as well. All regions are rounded up to a naturally aligned
multiple of 64 KB (for compatibility with 64k pages kernels) and recorded
in the UEFI memory map. The kernel proper reads those values and installs
the mappings in a dedicated set of page tables that are swapped in during
UEFI Runtime Services calls.

Acked-by: Leif Lindholm 
Acked-by: Matt Fleming 
Tested-by: Leif Lindholm 
Signed-off-by: Ard Biesheuvel