2019-06-04 16:11:30 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
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>
|
|
|
|
*/
|
|
|
|
|
2014-07-02 20:54:42 +08:00
|
|
|
#include <linux/efi.h>
|
2020-02-17 19:44:37 +08:00
|
|
|
#include <linux/libfdt.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
|
2018-12-07 06:50:37 +08:00
|
|
|
# define EFI_RT_VIRTUAL_LIMIT DEFAULT_MAP_WINDOW_64
|
2017-04-17 17:32:01 +08:00
|
|
|
#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;
|
2020-04-16 23:12:27 +08:00
|
|
|
static bool flat_va_mapping;
|
2017-04-05 00:09:10 +08:00
|
|
|
|
2020-04-17 00:38:06 +08:00
|
|
|
const efi_system_table_t *efi_system_table;
|
2019-12-24 23:10:15 +08:00
|
|
|
|
2019-12-24 23:10:19 +08:00
|
|
|
static struct screen_info *setup_graphics(void)
|
2016-04-26 04:06:54 +08:00
|
|
|
{
|
|
|
|
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;
|
efi/libstub: Rename efi_call_early/_runtime macros to be more intuitive
The macros efi_call_early and efi_call_runtime are used to call EFI
boot services and runtime services, respectively. However, the naming
is confusing, given that the early vs runtime distinction may suggest
that these are used for calling the same set of services either early
or late (== at runtime), while in reality, the sets of services they
can be used with are completely disjoint, and efi_call_runtime is also
only usable in 'early' code.
So do a global sweep to replace all occurrences with efi_bs_call or
efi_rt_call, respectively, where BS and RT match the idiom used by
the UEFI spec to refer to boot time or runtime services.
While at it, use 'func' as the macro parameter name for the function
pointers, which is less likely to collide and cause weird build errors.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Borislav Petkov <bp@alien8.de>
Cc: James Morse <james.morse@arm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191224151025.32482-24-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-24 23:10:23 +08:00
|
|
|
status = efi_bs_call(locate_handle, EFI_LOCATE_BY_PROTOCOL,
|
|
|
|
&gop_proto, NULL, &size, gop_handle);
|
2016-04-26 04:06:54 +08:00
|
|
|
if (status == EFI_BUFFER_TOO_SMALL) {
|
2019-12-24 23:10:19 +08:00
|
|
|
si = alloc_screen_info();
|
2016-04-26 04:06:54 +08:00
|
|
|
if (!si)
|
|
|
|
return NULL;
|
2020-04-27 03:49:46 +08:00
|
|
|
status = efi_setup_gop(si, &gop_proto, size);
|
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
free_screen_info(si);
|
|
|
|
return NULL;
|
|
|
|
}
|
2016-04-26 04:06:54 +08:00
|
|
|
}
|
|
|
|
return si;
|
|
|
|
}
|
2014-04-16 10:47:52 +08:00
|
|
|
|
2020-04-23 20:08:33 +08:00
|
|
|
static void install_memreserve_table(void)
|
2018-09-22 00:32:45 +08:00
|
|
|
{
|
|
|
|
struct linux_efi_memreserve *rsv;
|
|
|
|
efi_guid_t memreserve_table_guid = LINUX_EFI_MEMRESERVE_TABLE_GUID;
|
|
|
|
efi_status_t status;
|
|
|
|
|
efi/libstub: Rename efi_call_early/_runtime macros to be more intuitive
The macros efi_call_early and efi_call_runtime are used to call EFI
boot services and runtime services, respectively. However, the naming
is confusing, given that the early vs runtime distinction may suggest
that these are used for calling the same set of services either early
or late (== at runtime), while in reality, the sets of services they
can be used with are completely disjoint, and efi_call_runtime is also
only usable in 'early' code.
So do a global sweep to replace all occurrences with efi_bs_call or
efi_rt_call, respectively, where BS and RT match the idiom used by
the UEFI spec to refer to boot time or runtime services.
While at it, use 'func' as the macro parameter name for the function
pointers, which is less likely to collide and cause weird build errors.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Borislav Petkov <bp@alien8.de>
Cc: James Morse <james.morse@arm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191224151025.32482-24-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-24 23:10:23 +08:00
|
|
|
status = efi_bs_call(allocate_pool, EFI_LOADER_DATA, sizeof(*rsv),
|
|
|
|
(void **)&rsv);
|
2018-09-22 00:32:45 +08:00
|
|
|
if (status != EFI_SUCCESS) {
|
2020-05-01 02:28:35 +08:00
|
|
|
efi_err("Failed to allocate memreserve entry!\n");
|
2018-09-22 00:32:45 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
rsv->next = 0;
|
|
|
|
rsv->size = 0;
|
2018-11-30 01:12:28 +08:00
|
|
|
atomic_set(&rsv->count, 0);
|
2018-09-22 00:32:45 +08:00
|
|
|
|
efi/libstub: Rename efi_call_early/_runtime macros to be more intuitive
The macros efi_call_early and efi_call_runtime are used to call EFI
boot services and runtime services, respectively. However, the naming
is confusing, given that the early vs runtime distinction may suggest
that these are used for calling the same set of services either early
or late (== at runtime), while in reality, the sets of services they
can be used with are completely disjoint, and efi_call_runtime is also
only usable in 'early' code.
So do a global sweep to replace all occurrences with efi_bs_call or
efi_rt_call, respectively, where BS and RT match the idiom used by
the UEFI spec to refer to boot time or runtime services.
While at it, use 'func' as the macro parameter name for the function
pointers, which is less likely to collide and cause weird build errors.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Cc: Arvind Sankar <nivedita@alum.mit.edu>
Cc: Borislav Petkov <bp@alien8.de>
Cc: James Morse <james.morse@arm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: https://lkml.kernel.org/r/20191224151025.32482-24-ardb@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-12-24 23:10:23 +08:00
|
|
|
status = efi_bs_call(install_configuration_table,
|
|
|
|
&memreserve_table_guid, rsv);
|
2018-09-22 00:32:45 +08:00
|
|
|
if (status != EFI_SUCCESS)
|
2020-05-01 02:28:35 +08:00
|
|
|
efi_err("Failed to install memreserve config table!\n");
|
2018-09-22 00:32:45 +08:00
|
|
|
}
|
|
|
|
|
2020-02-11 00:02:42 +08:00
|
|
|
static unsigned long get_dram_base(void)
|
|
|
|
{
|
|
|
|
efi_status_t status;
|
|
|
|
unsigned long map_size, buff_size;
|
|
|
|
unsigned long membase = EFI_ERROR;
|
|
|
|
struct efi_memory_map map;
|
|
|
|
efi_memory_desc_t *md;
|
|
|
|
struct efi_boot_memmap boot_map;
|
|
|
|
|
|
|
|
boot_map.map = (efi_memory_desc_t **)&map.map;
|
|
|
|
boot_map.map_size = &map_size;
|
|
|
|
boot_map.desc_size = &map.desc_size;
|
|
|
|
boot_map.desc_ver = NULL;
|
|
|
|
boot_map.key_ptr = NULL;
|
|
|
|
boot_map.buff_size = &buff_size;
|
|
|
|
|
|
|
|
status = efi_get_memory_map(&boot_map);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
return membase;
|
|
|
|
|
|
|
|
map.map_end = map.map + map_size;
|
|
|
|
|
|
|
|
for_each_efi_memory_desc_in_map(&map, md) {
|
|
|
|
if (md->attribute & EFI_MEMORY_WB) {
|
|
|
|
if (membase > md->phys_addr)
|
|
|
|
membase = md->phys_addr;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
efi_bs_call(free_pool, map.map);
|
|
|
|
|
|
|
|
return membase;
|
|
|
|
}
|
2018-09-22 00:32:45 +08:00
|
|
|
|
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.
|
|
|
|
*/
|
2019-12-24 23:10:19 +08:00
|
|
|
efi_status_t handle_kernel_image(unsigned long *image_addr,
|
2014-07-02 20:54:42 +08:00
|
|
|
unsigned long *image_size,
|
|
|
|
unsigned long *reserve_addr,
|
|
|
|
unsigned long *reserve_size,
|
|
|
|
unsigned long dram_base,
|
|
|
|
efi_loaded_image_t *image);
|
2020-02-17 19:44:37 +08:00
|
|
|
|
|
|
|
asmlinkage void __noreturn efi_enter_kernel(unsigned long entrypoint,
|
|
|
|
unsigned long fdt_addr,
|
|
|
|
unsigned long fdt_size);
|
|
|
|
|
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.
|
|
|
|
*/
|
2020-05-23 17:01:57 +08:00
|
|
|
efi_status_t __efiapi efi_pe_entry(efi_handle_t handle,
|
|
|
|
efi_system_table_t *sys_table_arg)
|
2014-04-16 10:47:52 +08:00
|
|
|
{
|
|
|
|
efi_loaded_image_t *image;
|
|
|
|
efi_status_t status;
|
2020-02-17 19:44:37 +08:00
|
|
|
unsigned long image_addr;
|
2014-04-16 10:47:52 +08:00
|
|
|
unsigned long image_size = 0;
|
|
|
|
unsigned long dram_base;
|
|
|
|
/* addr/point and size pairs for memory management*/
|
efi/libstub: Take noinitrd cmdline argument into account for devpath initrd
One of the advantages of using what basically amounts to a callback
interface into the bootloader for loading the initrd is that it provides
a natural place for the bootloader or firmware to measure the initrd
contents while they are being passed to the kernel.
Unfortunately, this is not a guarantee that the initrd will in fact be
loaded and its /init invoked by the kernel, since the command line may
contain the 'noinitrd' option, in which case the initrd is ignored, but
this will not be reflected in the PCR that covers the initrd measurement.
This could be addressed by measuring the command line as well, and
including that PCR in the attestation policy, but this locks down the
command line completely, which may be too restrictive.
So let's take the noinitrd argument into account in the stub, too. This
forces any PCR that covers the initrd to assume a different value when
noinitrd is passed, allowing an attestation policy to disregard the
command line if there is no need to take its measurement into account
for other reasons.
As Peter points out, this would still require the agent that takes the
measurements to measure a separator event into the PCR in question at
ExitBootServices() time, to prevent replay attacks using the known
measurement from the TPM log.
Cc: Peter Jones <pjones@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-05 06:01:22 +08:00
|
|
|
unsigned long initrd_addr = 0;
|
efi/libstub: Rewrite file I/O routine
The file I/O routine that is used to load initrd or dtb files from
the EFI system partition suffers from a few issues:
- it converts the u8[] command line back to a UTF-16 string, which is
pointless since we only handle initrd or dtb arguments provided via
the loaded image protocol anyway, which is where we got the UTF-16[]
command line from in the first place when booting via the PE entry
point,
- in the far majority of cases, only a single initrd= option is present,
but it optimizes for multiple options, by going over the command line
twice, allocating heap buffers for dynamically sized arrays, etc.
- the coding style is hard to follow, with few comments, and all logic
including string parsing etc all combined in a single routine.
Let's fix this by rewriting most of it, based on the idea that in the
case of multiple initrds, we can just allocate a new, bigger buffer
and copy over the data before freeing the old one.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-11 00:02:44 +08:00
|
|
|
unsigned long 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;
|
|
|
|
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;
|
2020-02-11 02:29:36 +08:00
|
|
|
efi_properties_table_t *prop_tbl;
|
efi/libstub: Add support for loading the initrd from a device path
There are currently two ways to specify the initrd to be passed to the
Linux kernel when booting via the EFI stub:
- it can be passed as a initrd= command line option when doing a pure PE
boot (as opposed to the EFI handover protocol that exists for x86)
- otherwise, the bootloader or firmware can load the initrd into memory,
and pass the address and size via the bootparams struct (x86) or
device tree (ARM)
In the first case, we are limited to loading from the same file system
that the kernel was loaded from, and it is also problematic in a trusted
boot context, given that we cannot easily protect the command line from
tampering without either adding complicated white/blacklisting of boot
arguments or locking down the command line altogether.
In the second case, we force the bootloader to duplicate knowledge about
the boot protocol which is already encoded in the stub, and which may be
subject to change over time, e.g., bootparams struct definitions, memory
allocation/alignment requirements for the placement of the initrd etc etc.
In the ARM case, it also requires the bootloader to modify the hardware
description provided by the firmware, as it is passed in the same file.
On systems where the initrd is measured after loading, it creates a time
window where the initrd contents might be manipulated in memory before
handing over to the kernel.
Address these concerns by adding support for loading the initrd into
memory by invoking the EFI LoadFile2 protocol installed on a vendor
GUIDed device path that specifically designates a Linux initrd.
This addresses the above concerns, by putting the EFI stub in charge of
placement in memory and of passing the base and size to the kernel proper
(via whatever means it desires) while still leaving it up to the firmware
or bootloader to obtain the file contents, potentially from other file
systems than the one the kernel itself was loaded from. On platforms that
implement measured boot, it permits the firmware to take the measurement
right before the kernel actually consumes the contents.
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-04 07:45:14 +08:00
|
|
|
unsigned long max_addr;
|
2014-04-16 10:47:52 +08:00
|
|
|
|
2020-04-17 00:38:06 +08:00
|
|
|
efi_system_table = sys_table_arg;
|
2019-12-24 23:10:15 +08:00
|
|
|
|
2014-04-16 10:47:52 +08:00
|
|
|
/* Check if we were booted by the EFI firmware */
|
2020-04-17 00:38:06 +08:00
|
|
|
if (efi_system_table->hdr.signature != EFI_SYSTEM_TABLE_SIGNATURE) {
|
2020-02-17 19:44:37 +08:00
|
|
|
status = EFI_INVALID_PARAMETER;
|
2014-04-16 10:47:52 +08:00
|
|
|
goto fail;
|
2020-02-17 19:44:37 +08:00
|
|
|
}
|
2014-04-16 10:47:52 +08:00
|
|
|
|
2019-12-24 23:10:19 +08:00
|
|
|
status = check_platform_features();
|
2016-02-17 20:36:03 +08:00
|
|
|
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.
|
|
|
|
*/
|
2020-04-17 00:38:06 +08:00
|
|
|
status = efi_system_table->boottime->handle_protocol(handle,
|
2014-04-16 10:47:52 +08:00
|
|
|
&loaded_image_proto, (void *)&image);
|
|
|
|
if (status != EFI_SUCCESS) {
|
2020-05-01 02:28:35 +08:00
|
|
|
efi_err("Failed to get loaded image protocol\n");
|
2014-04-16 10:47:52 +08:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2019-12-24 23:10:19 +08:00
|
|
|
dram_base = get_dram_base();
|
2014-04-16 10:47:52 +08:00
|
|
|
if (dram_base == EFI_ERROR) {
|
2020-05-01 02:28:35 +08:00
|
|
|
efi_err("Failed to find DRAM base\n");
|
2020-02-17 19:44:37 +08:00
|
|
|
status = EFI_LOAD_ERROR;
|
2014-04-16 10:47:52 +08:00
|
|
|
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.
|
|
|
|
*/
|
2020-05-19 16:43:01 +08:00
|
|
|
cmdline_ptr = efi_convert_cmdline(image, &cmdline_size);
|
2014-04-16 10:47:52 +08:00
|
|
|
if (!cmdline_ptr) {
|
2020-05-01 02:28:35 +08:00
|
|
|
efi_err("getting command line via LOADED_IMAGE_PROTOCOL\n");
|
2020-02-17 19:44:37 +08:00
|
|
|
status = EFI_OUT_OF_RESOURCES;
|
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) ||
|
2020-05-01 02:28:43 +08:00
|
|
|
cmdline_size == 0) {
|
|
|
|
status = efi_parse_options(CONFIG_CMDLINE);
|
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
efi_err("Failed to parse options\n");
|
|
|
|
goto fail_free_cmdline;
|
|
|
|
}
|
|
|
|
}
|
2017-04-05 00:09:09 +08:00
|
|
|
|
2020-05-01 02:28:43 +08:00
|
|
|
if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && cmdline_size > 0) {
|
|
|
|
status = efi_parse_options(cmdline_ptr);
|
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
efi_err("Failed to parse options\n");
|
|
|
|
goto fail_free_cmdline;
|
|
|
|
}
|
|
|
|
}
|
2017-04-05 00:09:09 +08:00
|
|
|
|
2020-05-01 02:28:35 +08:00
|
|
|
efi_info("Booting Linux Kernel...\n");
|
2017-04-05 00:09:09 +08:00
|
|
|
|
2019-12-24 23:10:19 +08:00
|
|
|
si = setup_graphics();
|
2016-04-26 04:06:54 +08:00
|
|
|
|
2020-02-17 19:44:37 +08:00
|
|
|
status = handle_kernel_image(&image_addr, &image_size,
|
2016-01-26 21:48:29 +08:00
|
|
|
&reserve_addr,
|
|
|
|
&reserve_size,
|
|
|
|
dram_base, image);
|
|
|
|
if (status != EFI_SUCCESS) {
|
2020-05-01 02:28:35 +08:00
|
|
|
efi_err("Failed to relocate kernel\n");
|
2020-05-01 02:28:43 +08:00
|
|
|
goto fail_free_screeninfo;
|
2014-04-16 10:47:52 +08:00
|
|
|
}
|
|
|
|
|
2019-12-24 23:10:19 +08:00
|
|
|
efi_retrieve_tpm2_eventlog();
|
2019-11-07 16:24:21 +08:00
|
|
|
|
2017-08-25 23:50:15 +08:00
|
|
|
/* Ask the firmware to clear memory on unclean shutdown */
|
2019-12-24 23:10:19 +08:00
|
|
|
efi_enable_reset_attack_mitigation();
|
2017-08-25 23:50:15 +08:00
|
|
|
|
2019-12-24 23:10:19 +08:00
|
|
|
secure_boot = efi_get_secureboot();
|
2016-04-26 04:06:36 +08:00
|
|
|
|
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="))
|
2020-05-01 02:28:39 +08:00
|
|
|
efi_err("Ignoring DTB from command line.\n");
|
2014-04-03 23:46:58 +08:00
|
|
|
} else {
|
efi/libstub: Rewrite file I/O routine
The file I/O routine that is used to load initrd or dtb files from
the EFI system partition suffers from a few issues:
- it converts the u8[] command line back to a UTF-16 string, which is
pointless since we only handle initrd or dtb arguments provided via
the loaded image protocol anyway, which is where we got the UTF-16[]
command line from in the first place when booting via the PE entry
point,
- in the far majority of cases, only a single initrd= option is present,
but it optimizes for multiple options, by going over the command line
twice, allocating heap buffers for dynamically sized arrays, etc.
- the coding style is hard to follow, with few comments, and all logic
including string parsing etc all combined in a single routine.
Let's fix this by rewriting most of it, based on the idea that in the
case of multiple initrds, we can just allocate a new, bigger buffer
and copy over the data before freeing the old one.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-11 00:02:44 +08:00
|
|
|
status = efi_load_dtb(image, &fdt_addr, &fdt_size);
|
2014-04-16 10:47:52 +08:00
|
|
|
|
|
|
|
if (status != EFI_SUCCESS) {
|
2020-05-01 02:28:35 +08:00
|
|
|
efi_err("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) {
|
2020-05-01 02:28:35 +08:00
|
|
|
efi_info("Using DTB from command line\n");
|
2014-10-23 23:33:33 +08:00
|
|
|
} else {
|
2014-04-03 23:46:58 +08:00
|
|
|
/* Look for a device tree configuration table entry. */
|
2019-12-24 23:10:19 +08:00
|
|
|
fdt_addr = (uintptr_t)get_fdt(&fdt_size);
|
2014-10-23 23:33:33 +08:00
|
|
|
if (fdt_addr)
|
2020-05-01 02:28:35 +08:00
|
|
|
efi_info("Using DTB from configuration table\n");
|
2014-10-23 23:33:33 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!fdt_addr)
|
2020-05-01 02:28:35 +08:00
|
|
|
efi_info("Generating empty DTB\n");
|
2014-04-16 10:47:52 +08:00
|
|
|
|
2020-04-17 00:45:24 +08:00
|
|
|
if (!efi_noinitrd) {
|
efi/libstub: Take noinitrd cmdline argument into account for devpath initrd
One of the advantages of using what basically amounts to a callback
interface into the bootloader for loading the initrd is that it provides
a natural place for the bootloader or firmware to measure the initrd
contents while they are being passed to the kernel.
Unfortunately, this is not a guarantee that the initrd will in fact be
loaded and its /init invoked by the kernel, since the command line may
contain the 'noinitrd' option, in which case the initrd is ignored, but
this will not be reflected in the PCR that covers the initrd measurement.
This could be addressed by measuring the command line as well, and
including that PCR in the attestation policy, but this locks down the
command line completely, which may be too restrictive.
So let's take the noinitrd argument into account in the stub, too. This
forces any PCR that covers the initrd to assume a different value when
noinitrd is passed, allowing an attestation policy to disregard the
command line if there is no need to take its measurement into account
for other reasons.
As Peter points out, this would still require the agent that takes the
measurements to measure a separator event into the PCR in question at
ExitBootServices() time, to prevent replay attacks using the known
measurement from the TPM log.
Cc: Peter Jones <pjones@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-05 06:01:22 +08:00
|
|
|
max_addr = efi_get_max_initrd_addr(dram_base, image_addr);
|
2020-05-01 02:28:41 +08:00
|
|
|
status = efi_load_initrd(image, &initrd_addr, &initrd_size,
|
|
|
|
ULONG_MAX, max_addr);
|
efi/libstub: Take noinitrd cmdline argument into account for devpath initrd
One of the advantages of using what basically amounts to a callback
interface into the bootloader for loading the initrd is that it provides
a natural place for the bootloader or firmware to measure the initrd
contents while they are being passed to the kernel.
Unfortunately, this is not a guarantee that the initrd will in fact be
loaded and its /init invoked by the kernel, since the command line may
contain the 'noinitrd' option, in which case the initrd is ignored, but
this will not be reflected in the PCR that covers the initrd measurement.
This could be addressed by measuring the command line as well, and
including that PCR in the attestation policy, but this locks down the
command line completely, which may be too restrictive.
So let's take the noinitrd argument into account in the stub, too. This
forces any PCR that covers the initrd to assume a different value when
noinitrd is passed, allowing an attestation policy to disregard the
command line if there is no need to take its measurement into account
for other reasons.
As Peter points out, this would still require the agent that takes the
measurements to measure a separator event into the PCR in question at
ExitBootServices() time, to prevent replay attacks using the known
measurement from the TPM log.
Cc: Peter Jones <pjones@redhat.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-05 06:01:22 +08:00
|
|
|
if (status != EFI_SUCCESS)
|
2020-05-01 02:28:35 +08:00
|
|
|
efi_err("Failed to load initrd!\n");
|
efi/libstub: Add support for loading the initrd from a device path
There are currently two ways to specify the initrd to be passed to the
Linux kernel when booting via the EFI stub:
- it can be passed as a initrd= command line option when doing a pure PE
boot (as opposed to the EFI handover protocol that exists for x86)
- otherwise, the bootloader or firmware can load the initrd into memory,
and pass the address and size via the bootparams struct (x86) or
device tree (ARM)
In the first case, we are limited to loading from the same file system
that the kernel was loaded from, and it is also problematic in a trusted
boot context, given that we cannot easily protect the command line from
tampering without either adding complicated white/blacklisting of boot
arguments or locking down the command line altogether.
In the second case, we force the bootloader to duplicate knowledge about
the boot protocol which is already encoded in the stub, and which may be
subject to change over time, e.g., bootparams struct definitions, memory
allocation/alignment requirements for the placement of the initrd etc etc.
In the ARM case, it also requires the bootloader to modify the hardware
description provided by the firmware, as it is passed in the same file.
On systems where the initrd is measured after loading, it creates a time
window where the initrd contents might be manipulated in memory before
handing over to the kernel.
Address these concerns by adding support for loading the initrd into
memory by invoking the EFI LoadFile2 protocol installed on a vendor
GUIDed device path that specifically designates a Linux initrd.
This addresses the above concerns, by putting the EFI stub in charge of
placement in memory and of passing the base and size to the kernel proper
(via whatever means it desires) while still leaving it up to the firmware
or bootloader to obtain the file contents, potentially from other file
systems than the one the kernel itself was loaded from. On platforms that
implement measured boot, it permits the firmware to take the measurement
right before the kernel actually consumes the contents.
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-04 07:45:14 +08:00
|
|
|
}
|
2014-04-16 10:47:52 +08:00
|
|
|
|
2019-12-24 23:10:19 +08:00
|
|
|
efi_random_get_seed();
|
2016-11-13 05:32:33 +08:00
|
|
|
|
2020-02-11 02:29:36 +08:00
|
|
|
/*
|
|
|
|
* If the NX PE data feature is enabled in the properties table, we
|
|
|
|
* should take care not to create a virtual mapping that changes the
|
|
|
|
* relative placement of runtime services code and data regions, as
|
|
|
|
* they may belong to the same PE/COFF executable image in memory.
|
|
|
|
* The easiest way to achieve that is to simply use a 1:1 mapping.
|
|
|
|
*/
|
|
|
|
prop_tbl = get_efi_config_table(EFI_PROPERTIES_TABLE_GUID);
|
|
|
|
flat_va_mapping = prop_tbl &&
|
|
|
|
(prop_tbl->memory_protection_attribute &
|
|
|
|
EFI_PROPERTIES_RUNTIME_MEMORY_PROTECTION_NON_EXECUTABLE_PE_DATA);
|
|
|
|
|
2017-10-25 18:04:48 +08:00
|
|
|
/* hibernation expects the runtime regions to stay in the same place */
|
2020-04-17 00:45:24 +08:00
|
|
|
if (!IS_ENABLED(CONFIG_HIBERNATION) && !efi_nokaslr && !flat_va_mapping) {
|
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;
|
|
|
|
|
2019-12-24 23:10:19 +08:00
|
|
|
status = efi_get_random_bytes(sizeof(rnd), (u8 *)&rnd);
|
2017-04-05 00:09:10 +08:00
|
|
|
if (status == EFI_SUCCESS) {
|
|
|
|
virtmap_base = EFI_RT_VIRTUAL_BASE +
|
|
|
|
(((headroom >> 21) * rnd) >> (32 - 21));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-12-24 23:10:19 +08:00
|
|
|
install_memreserve_table();
|
2018-09-22 00:32:45 +08:00
|
|
|
|
2020-02-17 19:44:37 +08:00
|
|
|
status = allocate_new_fdt_and_exit_boot(handle, &fdt_addr,
|
|
|
|
efi_get_max_fdt_addr(dram_base),
|
|
|
|
initrd_addr, initrd_size,
|
|
|
|
cmdline_ptr, fdt_addr, fdt_size);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
goto fail_free_initrd;
|
2014-04-16 10:47:52 +08:00
|
|
|
|
2020-02-17 19:44:37 +08:00
|
|
|
efi_enter_kernel(image_addr, fdt_addr, fdt_totalsize((void *)fdt_addr));
|
|
|
|
/* not reached */
|
2014-04-16 10:47:52 +08:00
|
|
|
|
2020-02-17 19:44:37 +08:00
|
|
|
fail_free_initrd:
|
2020-05-01 02:28:35 +08:00
|
|
|
efi_err("Failed to update FDT and exit boot services\n");
|
2014-04-16 10:47:52 +08:00
|
|
|
|
2019-12-24 23:10:19 +08:00
|
|
|
efi_free(initrd_size, initrd_addr);
|
|
|
|
efi_free(fdt_size, fdt_addr);
|
2014-04-16 10:47:52 +08:00
|
|
|
|
|
|
|
fail_free_image:
|
2020-02-17 19:44:37 +08:00
|
|
|
efi_free(image_size, image_addr);
|
2019-12-24 23:10:19 +08:00
|
|
|
efi_free(reserve_size, reserve_addr);
|
2020-05-01 02:28:43 +08:00
|
|
|
fail_free_screeninfo:
|
2019-12-24 23:10:19 +08:00
|
|
|
free_screen_info(si);
|
2020-05-01 02:28:43 +08:00
|
|
|
fail_free_cmdline:
|
2020-05-19 16:43:01 +08:00
|
|
|
efi_bs_call(free_pool, cmdline_ptr);
|
2014-04-16 10:47:52 +08:00
|
|
|
fail:
|
2020-02-17 19:44:37 +08:00
|
|
|
return status;
|
2014-04-16 10:47:52 +08:00
|
|
|
}
|
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;
|
2020-02-11 02:29:36 +08:00
|
|
|
efi_memory_desc_t *in, *out = runtime_map;
|
2014-10-20 22:27:26 +08:00
|
|
|
int l;
|
|
|
|
|
2020-02-11 02:29:36 +08:00
|
|
|
for (l = 0; l < map_size; l += desc_size) {
|
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;
|
|
|
|
|
2020-02-11 02:29:36 +08:00
|
|
|
in->virt_addr = in->phys_addr;
|
2020-04-17 00:45:24 +08:00
|
|
|
if (efi_novamap) {
|
efi/arm/arm64: Allow SetVirtualAddressMap() to be omitted
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@codeaurora.org>
Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: Alexander Graf <agraf@suse.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Jones <pjones@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20190202094119.13230-8-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2019-02-02 17:41:16 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
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.
|
|
|
|
*/
|
2020-02-11 02:29:36 +08:00
|
|
|
if (!flat_va_mapping) {
|
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 = 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
|
|
|
|
2020-02-11 02:29:36 +08:00
|
|
|
in->virt_addr += efi_virt_base - paddr;
|
|
|
|
efi_virt_base += size;
|
|
|
|
}
|
2014-10-20 22:27:26 +08:00
|
|
|
|
|
|
|
memcpy(out, in, desc_size);
|
|
|
|
out = (void *)out + desc_size;
|
|
|
|
++*count;
|
|
|
|
}
|
|
|
|
}
|