2014-04-16 10:47:52 +08:00
|
|
|
/*
|
|
|
|
* EFI stub implementation that is shared by arm and arm64 architectures.
|
|
|
|
* This should be #included by the EFI stub implementation files.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2013,2014 Linaro Limited
|
|
|
|
* Roy Franz <roy.franz@linaro.org
|
|
|
|
* Copyright (C) 2013 Red Hat, Inc.
|
|
|
|
* Mark Salter <msalter@redhat.com>
|
|
|
|
*
|
|
|
|
* This file is part of the Linux kernel, and is made available under the
|
|
|
|
* terms of the GNU General Public License version 2.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2014-07-02 20:54:42 +08:00
|
|
|
#include <linux/efi.h>
|
arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regions
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 <msalter@redhat.com>
Tested-by: Mark Rutland <mark.rutland@arm.com> [UEFI 2.4 only]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Reviewed-by: Mark Salter <msalter@redhat.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org> # v4.0+
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
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 <mingo@kernel.org>
2015-09-26 06:02:19 +08:00
|
|
|
#include <linux/sort.h>
|
2014-07-02 20:54:42 +08:00
|
|
|
#include <asm/efi.h>
|
|
|
|
|
|
|
|
#include "efistub.h"
|
|
|
|
|
2017-04-05 00:09:10 +08:00
|
|
|
/*
|
|
|
|
* This is the base address at which to start allocating virtual memory ranges
|
|
|
|
* for UEFI Runtime Services. This is in the low TTBR0 range so that we can use
|
|
|
|
* any allocation we choose, and eliminate the risk of a conflict after kexec.
|
|
|
|
* The value chosen is the largest non-zero power of 2 suitable for this purpose
|
|
|
|
* both on 32-bit and 64-bit ARM CPUs, to maximize the likelihood that it can
|
|
|
|
* be mapped efficiently.
|
|
|
|
* Since 32-bit ARM could potentially execute with a 1G/3G user/kernel split,
|
|
|
|
* map everything below 1 GB. (512 MB is a reasonable upper bound for the
|
|
|
|
* entire footprint of the UEFI runtime services memory regions)
|
|
|
|
*/
|
|
|
|
#define EFI_RT_VIRTUAL_BASE SZ_512M
|
|
|
|
#define EFI_RT_VIRTUAL_SIZE SZ_512M
|
|
|
|
|
2017-04-17 17:32:01 +08:00
|
|
|
#ifdef CONFIG_ARM64
|
|
|
|
# define EFI_RT_VIRTUAL_LIMIT TASK_SIZE_64
|
|
|
|
#else
|
|
|
|
# define EFI_RT_VIRTUAL_LIMIT TASK_SIZE
|
|
|
|
#endif
|
|
|
|
|
2017-04-05 00:09:10 +08:00
|
|
|
static u64 virtmap_base = EFI_RT_VIRTUAL_BASE;
|
|
|
|
|
2014-07-02 20:54:42 +08:00
|
|
|
void efi_char16_printk(efi_system_table_t *sys_table_arg,
|
2014-04-16 10:47:52 +08:00
|
|
|
efi_char16_t *str)
|
|
|
|
{
|
|
|
|
struct efi_simple_text_output_protocol *out;
|
|
|
|
|
|
|
|
out = (struct efi_simple_text_output_protocol *)sys_table_arg->con_out;
|
|
|
|
out->output_string(out, str);
|
|
|
|
}
|
|
|
|
|
2016-04-26 04:06:54 +08:00
|
|
|
static struct screen_info *setup_graphics(efi_system_table_t *sys_table_arg)
|
|
|
|
{
|
|
|
|
efi_guid_t gop_proto = EFI_GRAPHICS_OUTPUT_PROTOCOL_GUID;
|
|
|
|
efi_status_t status;
|
|
|
|
unsigned long size;
|
|
|
|
void **gop_handle = NULL;
|
|
|
|
struct screen_info *si = NULL;
|
|
|
|
|
|
|
|
size = 0;
|
|
|
|
status = efi_call_early(locate_handle, EFI_LOCATE_BY_PROTOCOL,
|
|
|
|
&gop_proto, NULL, &size, gop_handle);
|
|
|
|
if (status == EFI_BUFFER_TOO_SMALL) {
|
|
|
|
si = alloc_screen_info(sys_table_arg);
|
|
|
|
if (!si)
|
|
|
|
return NULL;
|
|
|
|
efi_setup_gop(sys_table_arg, si, &gop_proto, size);
|
|
|
|
}
|
|
|
|
return si;
|
|
|
|
}
|
2014-04-16 10:47:52 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* This function handles the architcture specific differences between arm and
|
|
|
|
* arm64 regarding where the kernel image must be loaded and any memory that
|
|
|
|
* must be reserved. On failure it is required to free all
|
|
|
|
* all allocations it has made.
|
|
|
|
*/
|
2014-07-02 20:54:42 +08:00
|
|
|
efi_status_t handle_kernel_image(efi_system_table_t *sys_table,
|
|
|
|
unsigned long *image_addr,
|
|
|
|
unsigned long *image_size,
|
|
|
|
unsigned long *reserve_addr,
|
|
|
|
unsigned long *reserve_size,
|
|
|
|
unsigned long dram_base,
|
|
|
|
efi_loaded_image_t *image);
|
2014-04-16 10:47:52 +08:00
|
|
|
/*
|
|
|
|
* EFI entry point for the arm/arm64 EFI stubs. This is the entrypoint
|
|
|
|
* that is described in the PE/COFF header. Most of the code is the same
|
|
|
|
* for both archictectures, with the arch-specific code provided in the
|
|
|
|
* handle_kernel_image() function.
|
|
|
|
*/
|
2015-01-13 04:28:20 +08:00
|
|
|
unsigned long efi_entry(void *handle, efi_system_table_t *sys_table,
|
2014-04-16 10:47:52 +08:00
|
|
|
unsigned long *image_addr)
|
|
|
|
{
|
|
|
|
efi_loaded_image_t *image;
|
|
|
|
efi_status_t status;
|
|
|
|
unsigned long image_size = 0;
|
|
|
|
unsigned long dram_base;
|
|
|
|
/* addr/point and size pairs for memory management*/
|
|
|
|
unsigned long initrd_addr;
|
|
|
|
u64 initrd_size = 0;
|
2014-04-03 23:46:58 +08:00
|
|
|
unsigned long fdt_addr = 0; /* Original DTB */
|
2015-03-04 20:02:29 +08:00
|
|
|
unsigned long fdt_size = 0;
|
2014-04-16 10:47:52 +08:00
|
|
|
char *cmdline_ptr = NULL;
|
|
|
|
int cmdline_size = 0;
|
|
|
|
unsigned long new_fdt_addr;
|
|
|
|
efi_guid_t loaded_image_proto = LOADED_IMAGE_PROTOCOL_GUID;
|
|
|
|
unsigned long reserve_addr = 0;
|
|
|
|
unsigned long reserve_size = 0;
|
2017-02-06 19:22:43 +08:00
|
|
|
enum efi_secureboot_mode secure_boot;
|
2016-04-26 04:06:54 +08:00
|
|
|
struct screen_info *si;
|
2014-04-16 10:47:52 +08:00
|
|
|
|
|
|
|
/* Check if we were booted by the EFI firmware */
|
|
|
|
if (sys_table->hdr.signature != EFI_SYSTEM_TABLE_SIGNATURE)
|
|
|
|
goto fail;
|
|
|
|
|
2016-02-17 20:36:03 +08:00
|
|
|
status = check_platform_features(sys_table);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
goto fail;
|
|
|
|
|
2014-04-16 10:47:52 +08:00
|
|
|
/*
|
|
|
|
* Get a handle to the loaded image protocol. This is used to get
|
|
|
|
* information about the running image, such as size and the command
|
|
|
|
* line.
|
|
|
|
*/
|
|
|
|
status = sys_table->boottime->handle_protocol(handle,
|
|
|
|
&loaded_image_proto, (void *)&image);
|
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
pr_efi_err(sys_table, "Failed to get loaded image protocol\n");
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
dram_base = get_dram_base(sys_table);
|
|
|
|
if (dram_base == EFI_ERROR) {
|
|
|
|
pr_efi_err(sys_table, "Failed to find DRAM base\n");
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Get the command line from EFI, using the LOADED_IMAGE
|
|
|
|
* protocol. We are going to copy the command line into the
|
|
|
|
* device tree, so this can be allocated anywhere.
|
|
|
|
*/
|
|
|
|
cmdline_ptr = efi_convert_cmdline(sys_table, image, &cmdline_size);
|
|
|
|
if (!cmdline_ptr) {
|
|
|
|
pr_efi_err(sys_table, "getting command line via LOADED_IMAGE_PROTOCOL\n");
|
2016-01-26 21:48:29 +08:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2017-04-05 00:09:09 +08:00
|
|
|
if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
|
|
|
|
IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
|
|
|
|
cmdline_size == 0)
|
|
|
|
efi_parse_options(CONFIG_CMDLINE);
|
|
|
|
|
|
|
|
if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && cmdline_size > 0)
|
|
|
|
efi_parse_options(cmdline_ptr);
|
|
|
|
|
|
|
|
pr_efi(sys_table, "Booting Linux Kernel...\n");
|
|
|
|
|
2016-04-26 04:06:54 +08:00
|
|
|
si = setup_graphics(sys_table);
|
|
|
|
|
2016-01-26 21:48:29 +08:00
|
|
|
status = handle_kernel_image(sys_table, image_addr, &image_size,
|
|
|
|
&reserve_addr,
|
|
|
|
&reserve_size,
|
|
|
|
dram_base, image);
|
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
pr_efi_err(sys_table, "Failed to relocate kernel\n");
|
|
|
|
goto fail_free_cmdline;
|
2014-04-16 10:47:52 +08:00
|
|
|
}
|
|
|
|
|
2017-08-25 23:50:15 +08:00
|
|
|
/* Ask the firmware to clear memory on unclean shutdown */
|
|
|
|
efi_enable_reset_attack_mitigation(sys_table);
|
|
|
|
|
2016-04-26 04:06:36 +08:00
|
|
|
secure_boot = efi_get_secureboot(sys_table);
|
|
|
|
|
2014-04-03 23:46:58 +08:00
|
|
|
/*
|
2017-02-06 19:22:43 +08:00
|
|
|
* Unauthenticated device tree data is a security hazard, so ignore
|
|
|
|
* 'dtb=' unless UEFI Secure Boot is disabled. We assume that secure
|
|
|
|
* boot is enabled if we can't determine its state.
|
2014-04-03 23:46:58 +08:00
|
|
|
*/
|
efi/libstub/arm: Add opt-in Kconfig option for the DTB loader
There are various ways a platform can provide a device tree binary
to the kernel, with different levels of sophistication:
- ideally, the UEFI firmware, which is tightly coupled with the
platform, provides a device tree image directly as a UEFI
configuration table, and typically permits the contents to be
manipulated either via menu options or via UEFI environment
variables that specify a replacement image,
- GRUB for ARM has a 'devicetree' directive which allows a device
tree image to be loaded from any location accessible to GRUB, and
supersede the one provided by the firmware,
- the EFI stub implements a dtb= command line option that allows a
device tree image to be loaded from a file residing in the same
file system as the one the kernel image was loaded from.
The dtb= command line option was never intended to be more than a
development feature, to allow the other options to be implemented
in parallel. So let's make it an opt-in feature that is disabled
by default, but can be re-enabled at will.
Note that we already disable the dtb= command line option when we
detect that we are running with UEFI Secure Boot enabled.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Alexander Graf <agraf@suse.de>
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711094040.12506-7-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-07-11 17:40:38 +08:00
|
|
|
if (!IS_ENABLED(CONFIG_EFI_ARMSTUB_DTB_LOADER) ||
|
|
|
|
secure_boot != efi_secureboot_mode_disabled) {
|
|
|
|
if (strstr(cmdline_ptr, "dtb="))
|
|
|
|
pr_efi(sys_table, "Ignoring DTB from command line.\n");
|
2014-04-03 23:46:58 +08:00
|
|
|
} else {
|
2014-04-16 10:47:52 +08:00
|
|
|
status = handle_cmdline_files(sys_table, image, cmdline_ptr,
|
|
|
|
"dtb=",
|
2015-03-04 20:02:29 +08:00
|
|
|
~0UL, &fdt_addr, &fdt_size);
|
2014-04-16 10:47:52 +08:00
|
|
|
|
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
pr_efi_err(sys_table, "Failed to load device tree!\n");
|
2016-01-26 21:48:29 +08:00
|
|
|
goto fail_free_image;
|
2014-04-16 10:47:52 +08:00
|
|
|
}
|
|
|
|
}
|
2014-10-23 23:33:33 +08:00
|
|
|
|
|
|
|
if (fdt_addr) {
|
|
|
|
pr_efi(sys_table, "Using DTB from command line\n");
|
|
|
|
} else {
|
2014-04-03 23:46:58 +08:00
|
|
|
/* Look for a device tree configuration table entry. */
|
2015-03-04 20:02:29 +08:00
|
|
|
fdt_addr = (uintptr_t)get_fdt(sys_table, &fdt_size);
|
2014-10-23 23:33:33 +08:00
|
|
|
if (fdt_addr)
|
|
|
|
pr_efi(sys_table, "Using DTB from configuration table\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!fdt_addr)
|
|
|
|
pr_efi(sys_table, "Generating empty DTB\n");
|
2014-04-16 10:47:52 +08:00
|
|
|
|
2017-04-05 00:02:37 +08:00
|
|
|
status = handle_cmdline_files(sys_table, image, cmdline_ptr, "initrd=",
|
|
|
|
efi_get_max_initrd_addr(dram_base,
|
|
|
|
*image_addr),
|
2014-04-16 10:47:52 +08:00
|
|
|
(unsigned long *)&initrd_addr,
|
|
|
|
(unsigned long *)&initrd_size);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
pr_efi_err(sys_table, "Failed initrd from command line!\n");
|
|
|
|
|
2016-11-13 05:32:33 +08:00
|
|
|
efi_random_get_seed(sys_table);
|
|
|
|
|
2017-10-25 18:04:48 +08:00
|
|
|
/* hibernation expects the runtime regions to stay in the same place */
|
|
|
|
if (!IS_ENABLED(CONFIG_HIBERNATION) && !nokaslr()) {
|
2017-04-05 00:09:10 +08:00
|
|
|
/*
|
|
|
|
* Randomize the base of the UEFI runtime services region.
|
|
|
|
* Preserve the 2 MB alignment of the region by taking a
|
|
|
|
* shift of 21 bit positions into account when scaling
|
|
|
|
* the headroom value using a 32-bit random value.
|
|
|
|
*/
|
2017-04-17 17:32:01 +08:00
|
|
|
static const u64 headroom = EFI_RT_VIRTUAL_LIMIT -
|
|
|
|
EFI_RT_VIRTUAL_BASE -
|
|
|
|
EFI_RT_VIRTUAL_SIZE;
|
2017-04-05 00:09:10 +08:00
|
|
|
u32 rnd;
|
|
|
|
|
|
|
|
status = efi_get_random_bytes(sys_table, sizeof(rnd),
|
|
|
|
(u8 *)&rnd);
|
|
|
|
if (status == EFI_SUCCESS) {
|
|
|
|
virtmap_base = EFI_RT_VIRTUAL_BASE +
|
|
|
|
(((headroom >> 21) * rnd) >> (32 - 21));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-04-16 10:47:52 +08:00
|
|
|
new_fdt_addr = fdt_addr;
|
|
|
|
status = allocate_new_fdt_and_exit_boot(sys_table, handle,
|
2017-04-05 00:02:37 +08:00
|
|
|
&new_fdt_addr, efi_get_max_fdt_addr(dram_base),
|
2014-04-16 10:47:52 +08:00
|
|
|
initrd_addr, initrd_size, cmdline_ptr,
|
|
|
|
fdt_addr, fdt_size);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If all went well, we need to return the FDT address to the
|
|
|
|
* calling function so it can be passed to kernel as part of
|
|
|
|
* the kernel boot protocol.
|
|
|
|
*/
|
|
|
|
if (status == EFI_SUCCESS)
|
|
|
|
return new_fdt_addr;
|
|
|
|
|
|
|
|
pr_efi_err(sys_table, "Failed to update FDT and exit boot services\n");
|
|
|
|
|
|
|
|
efi_free(sys_table, initrd_size, initrd_addr);
|
|
|
|
efi_free(sys_table, fdt_size, fdt_addr);
|
|
|
|
|
|
|
|
fail_free_image:
|
|
|
|
efi_free(sys_table, image_size, *image_addr);
|
|
|
|
efi_free(sys_table, reserve_size, reserve_addr);
|
2016-01-26 21:48:29 +08:00
|
|
|
fail_free_cmdline:
|
2016-04-26 04:06:54 +08:00
|
|
|
free_screen_info(sys_table, si);
|
2016-01-26 21:48:29 +08:00
|
|
|
efi_free(sys_table, cmdline_size, (unsigned long)cmdline_ptr);
|
2014-04-16 10:47:52 +08:00
|
|
|
fail:
|
|
|
|
return EFI_ERROR;
|
|
|
|
}
|
2014-10-20 22:27:26 +08:00
|
|
|
|
arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regions
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 <msalter@redhat.com>
Tested-by: Mark Rutland <mark.rutland@arm.com> [UEFI 2.4 only]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Reviewed-by: Mark Salter <msalter@redhat.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org> # v4.0+
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
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 <mingo@kernel.org>
2015-09-26 06:02:19 +08:00
|
|
|
static int cmp_mem_desc(const void *l, const void *r)
|
|
|
|
{
|
|
|
|
const efi_memory_desc_t *left = l, *right = r;
|
|
|
|
|
|
|
|
return (left->phys_addr > right->phys_addr) ? 1 : -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Returns whether region @left ends exactly where region @right starts,
|
|
|
|
* or false if either argument is NULL.
|
|
|
|
*/
|
|
|
|
static bool regions_are_adjacent(efi_memory_desc_t *left,
|
|
|
|
efi_memory_desc_t *right)
|
|
|
|
{
|
|
|
|
u64 left_end;
|
|
|
|
|
|
|
|
if (left == NULL || right == NULL)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
left_end = left->phys_addr + left->num_pages * EFI_PAGE_SIZE;
|
|
|
|
|
|
|
|
return left_end == right->phys_addr;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Returns whether region @left and region @right have compatible memory type
|
|
|
|
* mapping attributes, and are both EFI_MEMORY_RUNTIME regions.
|
|
|
|
*/
|
|
|
|
static bool regions_have_compatible_memory_type_attrs(efi_memory_desc_t *left,
|
|
|
|
efi_memory_desc_t *right)
|
|
|
|
{
|
|
|
|
static const u64 mem_type_mask = EFI_MEMORY_WB | EFI_MEMORY_WT |
|
|
|
|
EFI_MEMORY_WC | EFI_MEMORY_UC |
|
|
|
|
EFI_MEMORY_RUNTIME;
|
|
|
|
|
|
|
|
return ((left->attribute ^ right->attribute) & mem_type_mask) == 0;
|
|
|
|
}
|
|
|
|
|
2014-10-20 22:27:26 +08:00
|
|
|
/*
|
|
|
|
* efi_get_virtmap() - create a virtual mapping for the EFI memory map
|
|
|
|
*
|
|
|
|
* This function populates the virt_addr fields of all memory region descriptors
|
|
|
|
* in @memory_map whose EFI_MEMORY_RUNTIME attribute is set. Those descriptors
|
|
|
|
* are also copied to @runtime_map, and their total count is returned in @count.
|
|
|
|
*/
|
|
|
|
void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,
|
|
|
|
unsigned long desc_size, efi_memory_desc_t *runtime_map,
|
|
|
|
int *count)
|
|
|
|
{
|
2017-04-05 00:09:10 +08:00
|
|
|
u64 efi_virt_base = virtmap_base;
|
arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regions
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 <msalter@redhat.com>
Tested-by: Mark Rutland <mark.rutland@arm.com> [UEFI 2.4 only]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Reviewed-by: Mark Salter <msalter@redhat.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org> # v4.0+
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
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 <mingo@kernel.org>
2015-09-26 06:02:19 +08:00
|
|
|
efi_memory_desc_t *in, *prev = NULL, *out = runtime_map;
|
2014-10-20 22:27:26 +08:00
|
|
|
int l;
|
|
|
|
|
arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regions
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 <msalter@redhat.com>
Tested-by: Mark Rutland <mark.rutland@arm.com> [UEFI 2.4 only]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Reviewed-by: Mark Salter <msalter@redhat.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org> # v4.0+
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
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 <mingo@kernel.org>
2015-09-26 06:02:19 +08:00
|
|
|
/*
|
|
|
|
* To work around potential issues with the Properties Table feature
|
|
|
|
* introduced in UEFI 2.5, which may split PE/COFF executable images
|
|
|
|
* in memory into several RuntimeServicesCode and RuntimeServicesData
|
|
|
|
* regions, we need to preserve the relative offsets between adjacent
|
|
|
|
* EFI_MEMORY_RUNTIME regions with the same memory type attributes.
|
|
|
|
* The easiest way to find adjacent regions is to sort the memory map
|
|
|
|
* before traversing it.
|
|
|
|
*/
|
efi/libstub: arm: omit sorting of the UEFI memory map
ARM shares its EFI stub implementation with arm64, which has some
special handling in the virtual remapping code to
a) make sure that we can map everything even if the OS executes
with 64k page size, and
b) make sure that adjacent regions with the same attributes are not
reordered or moved apart in memory.
The latter is a workaround for a 'feature' that was shortly recommended
by UEFI spec v2.5, but deprecated shortly after, due to the fact that
it broke many OS installers, including non-Linux ones, and it was never
widely implemented for ARM systems. Before implementing b), the arm64
code simply rounded up all regions to 64 KB granularity, but given that
that results in moving adjacent regions apart, it had to be refined when
b) was implemented.
The adjacency check requires a sort() pass, due to the fact that the
UEFI spec does not mandate any ordering, and the inclusion of the
lib/sort.c code into the ARM EFI stub is causing some trouble with
the decompressor build due to the fact that its EXPORT_SYMBOL() call
triggers the creation of ksymtab/kcrctab sections.
So let's simply do away with the adjacency check for ARM, and simply put
all UEFI runtime regions together if they have the same memory attributes.
This is guaranteed to work, given that ARM only supports 4 KB pages,
and allows us to remove the sort() call entirely.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Tested-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2017-10-22 22:14:57 +08:00
|
|
|
if (IS_ENABLED(CONFIG_ARM64))
|
|
|
|
sort(memory_map, map_size / desc_size, desc_size, cmp_mem_desc,
|
|
|
|
NULL);
|
arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regions
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 <msalter@redhat.com>
Tested-by: Mark Rutland <mark.rutland@arm.com> [UEFI 2.4 only]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Reviewed-by: Mark Salter <msalter@redhat.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org> # v4.0+
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
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 <mingo@kernel.org>
2015-09-26 06:02:19 +08:00
|
|
|
|
|
|
|
for (l = 0; l < map_size; l += desc_size, prev = in) {
|
2014-10-20 22:27:26 +08:00
|
|
|
u64 paddr, size;
|
|
|
|
|
arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regions
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 <msalter@redhat.com>
Tested-by: Mark Rutland <mark.rutland@arm.com> [UEFI 2.4 only]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Reviewed-by: Mark Salter <msalter@redhat.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org> # v4.0+
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
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 <mingo@kernel.org>
2015-09-26 06:02:19 +08:00
|
|
|
in = (void *)memory_map + l;
|
2014-10-20 22:27:26 +08:00
|
|
|
if (!(in->attribute & EFI_MEMORY_RUNTIME))
|
|
|
|
continue;
|
|
|
|
|
arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regions
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 <msalter@redhat.com>
Tested-by: Mark Rutland <mark.rutland@arm.com> [UEFI 2.4 only]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Reviewed-by: Mark Salter <msalter@redhat.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org> # v4.0+
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
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 <mingo@kernel.org>
2015-09-26 06:02:19 +08:00
|
|
|
paddr = in->phys_addr;
|
|
|
|
size = in->num_pages * EFI_PAGE_SIZE;
|
|
|
|
|
2014-10-20 22:27:26 +08:00
|
|
|
/*
|
|
|
|
* Make the mapping compatible with 64k pages: this allows
|
|
|
|
* a 4k page size kernel to kexec a 64k page size kernel and
|
|
|
|
* vice versa.
|
|
|
|
*/
|
efi/libstub: arm: omit sorting of the UEFI memory map
ARM shares its EFI stub implementation with arm64, which has some
special handling in the virtual remapping code to
a) make sure that we can map everything even if the OS executes
with 64k page size, and
b) make sure that adjacent regions with the same attributes are not
reordered or moved apart in memory.
The latter is a workaround for a 'feature' that was shortly recommended
by UEFI spec v2.5, but deprecated shortly after, due to the fact that
it broke many OS installers, including non-Linux ones, and it was never
widely implemented for ARM systems. Before implementing b), the arm64
code simply rounded up all regions to 64 KB granularity, but given that
that results in moving adjacent regions apart, it had to be refined when
b) was implemented.
The adjacency check requires a sort() pass, due to the fact that the
UEFI spec does not mandate any ordering, and the inclusion of the
lib/sort.c code into the ARM EFI stub is causing some trouble with
the decompressor build due to the fact that its EXPORT_SYMBOL() call
triggers the creation of ksymtab/kcrctab sections.
So let's simply do away with the adjacency check for ARM, and simply put
all UEFI runtime regions together if they have the same memory attributes.
This is guaranteed to work, given that ARM only supports 4 KB pages,
and allows us to remove the sort() call entirely.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Tested-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2017-10-22 22:14:57 +08:00
|
|
|
if ((IS_ENABLED(CONFIG_ARM64) &&
|
|
|
|
!regions_are_adjacent(prev, in)) ||
|
arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regions
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 <msalter@redhat.com>
Tested-by: Mark Rutland <mark.rutland@arm.com> [UEFI 2.4 only]
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
Reviewed-by: Mark Salter <msalter@redhat.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Cc: <stable@vger.kernel.org> # v4.0+
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
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 <mingo@kernel.org>
2015-09-26 06:02:19 +08:00
|
|
|
!regions_have_compatible_memory_type_attrs(prev, in)) {
|
|
|
|
|
|
|
|
paddr = round_down(in->phys_addr, SZ_64K);
|
|
|
|
size += in->phys_addr - paddr;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Avoid wasting memory on PTEs by choosing a virtual
|
|
|
|
* base that is compatible with section mappings if this
|
|
|
|
* region has the appropriate size and physical
|
|
|
|
* alignment. (Sections are 2 MB on 4k granule kernels)
|
|
|
|
*/
|
|
|
|
if (IS_ALIGNED(in->phys_addr, SZ_2M) && size >= SZ_2M)
|
|
|
|
efi_virt_base = round_up(efi_virt_base, SZ_2M);
|
|
|
|
else
|
|
|
|
efi_virt_base = round_up(efi_virt_base, SZ_64K);
|
|
|
|
}
|
2014-10-20 22:27:26 +08:00
|
|
|
|
|
|
|
in->virt_addr = efi_virt_base + in->phys_addr - paddr;
|
|
|
|
efi_virt_base += size;
|
|
|
|
|
|
|
|
memcpy(out, in, desc_size);
|
|
|
|
out = (void *)out + desc_size;
|
|
|
|
++*count;
|
|
|
|
}
|
|
|
|
}
|