2019-06-04 10:11:30 +02:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2014-04-15 22:47:52 -04: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 14:54:42 +02:00
|
|
|
#include <linux/efi.h>
|
2020-02-17 12:44:37 +01:00
|
|
|
#include <linux/libfdt.h>
|
2014-07-02 14:54:42 +02:00
|
|
|
#include <asm/efi.h>
|
|
|
|
|
|
|
|
#include "efistub.h"
|
|
|
|
|
2017-04-04 17:09:10 +01: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 10:32:01 +01:00
|
|
|
#ifdef CONFIG_ARM64
|
2018-12-06 22:50:37 +00:00
|
|
|
# define EFI_RT_VIRTUAL_LIMIT DEFAULT_MAP_WINDOW_64
|
2017-04-17 10:32:01 +01:00
|
|
|
#else
|
|
|
|
# define EFI_RT_VIRTUAL_LIMIT TASK_SIZE
|
|
|
|
#endif
|
|
|
|
|
2017-04-04 17:09:10 +01:00
|
|
|
static u64 virtmap_base = EFI_RT_VIRTUAL_BASE;
|
2020-02-10 19:29:36 +01:00
|
|
|
static bool __efistub_global flat_va_mapping;
|
2017-04-04 17:09:10 +01:00
|
|
|
|
2019-12-24 16:10:24 +01:00
|
|
|
static efi_system_table_t *__efistub_global sys_table;
|
2019-12-24 16:10:15 +01:00
|
|
|
|
|
|
|
__pure efi_system_table_t *efi_system_table(void)
|
|
|
|
{
|
|
|
|
return sys_table;
|
|
|
|
}
|
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
static struct screen_info *setup_graphics(void)
|
2016-04-25 21:06:54 +01: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 16:10:23 +01:00
|
|
|
status = efi_bs_call(locate_handle, EFI_LOCATE_BY_PROTOCOL,
|
|
|
|
&gop_proto, NULL, &size, gop_handle);
|
2016-04-25 21:06:54 +01:00
|
|
|
if (status == EFI_BUFFER_TOO_SMALL) {
|
2019-12-24 16:10:19 +01:00
|
|
|
si = alloc_screen_info();
|
2016-04-25 21:06:54 +01:00
|
|
|
if (!si)
|
|
|
|
return NULL;
|
2019-12-24 16:10:19 +01:00
|
|
|
efi_setup_gop(si, &gop_proto, size);
|
2016-04-25 21:06:54 +01:00
|
|
|
}
|
|
|
|
return si;
|
|
|
|
}
|
2014-04-15 22:47:52 -04:00
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
void install_memreserve_table(void)
|
2018-09-21 09:32:45 -07: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 16:10:23 +01:00
|
|
|
status = efi_bs_call(allocate_pool, EFI_LOADER_DATA, sizeof(*rsv),
|
|
|
|
(void **)&rsv);
|
2018-09-21 09:32:45 -07:00
|
|
|
if (status != EFI_SUCCESS) {
|
2019-12-24 16:10:18 +01:00
|
|
|
pr_efi_err("Failed to allocate memreserve entry!\n");
|
2018-09-21 09:32:45 -07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
rsv->next = 0;
|
|
|
|
rsv->size = 0;
|
2018-11-29 18:12:28 +01:00
|
|
|
atomic_set(&rsv->count, 0);
|
2018-09-21 09:32:45 -07: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 16:10:23 +01:00
|
|
|
status = efi_bs_call(install_configuration_table,
|
|
|
|
&memreserve_table_guid, rsv);
|
2018-09-21 09:32:45 -07:00
|
|
|
if (status != EFI_SUCCESS)
|
2019-12-24 16:10:18 +01:00
|
|
|
pr_efi_err("Failed to install memreserve config table!\n");
|
2018-09-21 09:32:45 -07:00
|
|
|
}
|
|
|
|
|
2020-02-10 17:02:42 +01: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-21 09:32:45 -07:00
|
|
|
|
2014-04-15 22:47:52 -04: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 16:10:19 +01:00
|
|
|
efi_status_t handle_kernel_image(unsigned long *image_addr,
|
2014-07-02 14:54:42 +02: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 12:44:37 +01:00
|
|
|
|
|
|
|
asmlinkage void __noreturn efi_enter_kernel(unsigned long entrypoint,
|
|
|
|
unsigned long fdt_addr,
|
|
|
|
unsigned long fdt_size);
|
|
|
|
|
2014-04-15 22:47:52 -04: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-02-17 12:44:37 +01:00
|
|
|
efi_status_t efi_entry(efi_handle_t handle, efi_system_table_t *sys_table_arg)
|
2014-04-15 22:47:52 -04:00
|
|
|
{
|
|
|
|
efi_loaded_image_t *image;
|
|
|
|
efi_status_t status;
|
2020-02-17 12:44:37 +01:00
|
|
|
unsigned long image_addr;
|
2014-04-15 22:47:52 -04:00
|
|
|
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 17:46:58 +02:00
|
|
|
unsigned long fdt_addr = 0; /* Original DTB */
|
2015-03-04 13:02:29 +01:00
|
|
|
unsigned long fdt_size = 0;
|
2014-04-15 22:47:52 -04: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 11:22:43 +00:00
|
|
|
enum efi_secureboot_mode secure_boot;
|
2016-04-25 21:06:54 +01:00
|
|
|
struct screen_info *si;
|
2020-02-10 19:29:36 +01:00
|
|
|
efi_properties_table_t *prop_tbl;
|
2014-04-15 22:47:52 -04:00
|
|
|
|
2019-12-24 16:10:15 +01:00
|
|
|
sys_table = sys_table_arg;
|
|
|
|
|
2014-04-15 22:47:52 -04:00
|
|
|
/* Check if we were booted by the EFI firmware */
|
2020-02-17 12:44:37 +01:00
|
|
|
if (sys_table->hdr.signature != EFI_SYSTEM_TABLE_SIGNATURE) {
|
|
|
|
status = EFI_INVALID_PARAMETER;
|
2014-04-15 22:47:52 -04:00
|
|
|
goto fail;
|
2020-02-17 12:44:37 +01:00
|
|
|
}
|
2014-04-15 22:47:52 -04:00
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
status = check_platform_features();
|
2016-02-17 12:36:03 +00:00
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
goto fail;
|
|
|
|
|
2014-04-15 22:47:52 -04: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) {
|
2019-12-24 16:10:18 +01:00
|
|
|
pr_efi_err("Failed to get loaded image protocol\n");
|
2014-04-15 22:47:52 -04:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
dram_base = get_dram_base();
|
2014-04-15 22:47:52 -04:00
|
|
|
if (dram_base == EFI_ERROR) {
|
2019-12-24 16:10:18 +01:00
|
|
|
pr_efi_err("Failed to find DRAM base\n");
|
2020-02-17 12:44:37 +01:00
|
|
|
status = EFI_LOAD_ERROR;
|
2014-04-15 22:47:52 -04: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-02-10 17:02:40 +01:00
|
|
|
cmdline_ptr = efi_convert_cmdline(image, &cmdline_size, ULONG_MAX);
|
2014-04-15 22:47:52 -04:00
|
|
|
if (!cmdline_ptr) {
|
2019-12-24 16:10:18 +01:00
|
|
|
pr_efi_err("getting command line via LOADED_IMAGE_PROTOCOL\n");
|
2020-02-17 12:44:37 +01:00
|
|
|
status = EFI_OUT_OF_RESOURCES;
|
2016-01-26 14:48:29 +01:00
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2017-04-04 17:09:09 +01: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);
|
|
|
|
|
2019-12-24 16:10:18 +01:00
|
|
|
pr_efi("Booting Linux Kernel...\n");
|
2017-04-04 17:09:09 +01:00
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
si = setup_graphics();
|
2016-04-25 21:06:54 +01:00
|
|
|
|
2020-02-17 12:44:37 +01:00
|
|
|
status = handle_kernel_image(&image_addr, &image_size,
|
2016-01-26 14:48:29 +01:00
|
|
|
&reserve_addr,
|
|
|
|
&reserve_size,
|
|
|
|
dram_base, image);
|
|
|
|
if (status != EFI_SUCCESS) {
|
2019-12-24 16:10:18 +01:00
|
|
|
pr_efi_err("Failed to relocate kernel\n");
|
2016-01-26 14:48:29 +01:00
|
|
|
goto fail_free_cmdline;
|
2014-04-15 22:47:52 -04:00
|
|
|
}
|
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
efi_retrieve_tpm2_eventlog();
|
2019-11-07 16:24:21 +08:00
|
|
|
|
2017-08-25 16:50:15 +01:00
|
|
|
/* Ask the firmware to clear memory on unclean shutdown */
|
2019-12-24 16:10:19 +01:00
|
|
|
efi_enable_reset_attack_mitigation();
|
2017-08-25 16:50:15 +01:00
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
secure_boot = efi_get_secureboot();
|
2016-04-25 21:06:36 +01:00
|
|
|
|
2014-04-03 17:46:58 +02:00
|
|
|
/*
|
2017-02-06 11:22:43 +00: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 17:46:58 +02: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 11:40:38 +02:00
|
|
|
if (!IS_ENABLED(CONFIG_EFI_ARMSTUB_DTB_LOADER) ||
|
|
|
|
secure_boot != efi_secureboot_mode_disabled) {
|
|
|
|
if (strstr(cmdline_ptr, "dtb="))
|
2019-12-24 16:10:18 +01:00
|
|
|
pr_efi("Ignoring DTB from command line.\n");
|
2014-04-03 17:46:58 +02:00
|
|
|
} else {
|
2019-12-24 16:10:19 +01:00
|
|
|
status = handle_cmdline_files(image, cmdline_ptr, "dtb=",
|
2015-03-04 13:02:29 +01:00
|
|
|
~0UL, &fdt_addr, &fdt_size);
|
2014-04-15 22:47:52 -04:00
|
|
|
|
|
|
|
if (status != EFI_SUCCESS) {
|
2019-12-24 16:10:18 +01:00
|
|
|
pr_efi_err("Failed to load device tree!\n");
|
2016-01-26 14:48:29 +01:00
|
|
|
goto fail_free_image;
|
2014-04-15 22:47:52 -04:00
|
|
|
}
|
|
|
|
}
|
2014-10-23 16:33:33 +01:00
|
|
|
|
|
|
|
if (fdt_addr) {
|
2019-12-24 16:10:18 +01:00
|
|
|
pr_efi("Using DTB from command line\n");
|
2014-10-23 16:33:33 +01:00
|
|
|
} else {
|
2014-04-03 17:46:58 +02:00
|
|
|
/* Look for a device tree configuration table entry. */
|
2019-12-24 16:10:19 +01:00
|
|
|
fdt_addr = (uintptr_t)get_fdt(&fdt_size);
|
2014-10-23 16:33:33 +01:00
|
|
|
if (fdt_addr)
|
2019-12-24 16:10:18 +01:00
|
|
|
pr_efi("Using DTB from configuration table\n");
|
2014-10-23 16:33:33 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!fdt_addr)
|
2019-12-24 16:10:18 +01:00
|
|
|
pr_efi("Generating empty DTB\n");
|
2014-04-15 22:47:52 -04:00
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
status = handle_cmdline_files(image, cmdline_ptr, "initrd=",
|
2017-04-04 17:02:37 +01:00
|
|
|
efi_get_max_initrd_addr(dram_base,
|
2020-02-17 12:44:37 +01:00
|
|
|
image_addr),
|
2014-04-15 22:47:52 -04:00
|
|
|
(unsigned long *)&initrd_addr,
|
|
|
|
(unsigned long *)&initrd_size);
|
|
|
|
if (status != EFI_SUCCESS)
|
2019-12-24 16:10:18 +01:00
|
|
|
pr_efi_err("Failed initrd from command line!\n");
|
2014-04-15 22:47:52 -04:00
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
efi_random_get_seed();
|
2016-11-12 21:32:33 +00:00
|
|
|
|
2020-02-10 19:29:36 +01: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 11:04:48 +01:00
|
|
|
/* hibernation expects the runtime regions to stay in the same place */
|
2020-02-10 19:29:36 +01:00
|
|
|
if (!IS_ENABLED(CONFIG_HIBERNATION) && !nokaslr() && !flat_va_mapping) {
|
2017-04-04 17:09:10 +01: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 10:32:01 +01:00
|
|
|
static const u64 headroom = EFI_RT_VIRTUAL_LIMIT -
|
|
|
|
EFI_RT_VIRTUAL_BASE -
|
|
|
|
EFI_RT_VIRTUAL_SIZE;
|
2017-04-04 17:09:10 +01:00
|
|
|
u32 rnd;
|
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
status = efi_get_random_bytes(sizeof(rnd), (u8 *)&rnd);
|
2017-04-04 17:09:10 +01:00
|
|
|
if (status == EFI_SUCCESS) {
|
|
|
|
virtmap_base = EFI_RT_VIRTUAL_BASE +
|
|
|
|
(((headroom >> 21) * rnd) >> (32 - 21));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
install_memreserve_table();
|
2018-09-21 09:32:45 -07:00
|
|
|
|
2020-02-17 12:44:37 +01: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-15 22:47:52 -04:00
|
|
|
|
2020-02-17 12:44:37 +01:00
|
|
|
efi_enter_kernel(image_addr, fdt_addr, fdt_totalsize((void *)fdt_addr));
|
|
|
|
/* not reached */
|
2014-04-15 22:47:52 -04:00
|
|
|
|
2020-02-17 12:44:37 +01:00
|
|
|
fail_free_initrd:
|
2019-12-24 16:10:18 +01:00
|
|
|
pr_efi_err("Failed to update FDT and exit boot services\n");
|
2014-04-15 22:47:52 -04:00
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
efi_free(initrd_size, initrd_addr);
|
|
|
|
efi_free(fdt_size, fdt_addr);
|
2014-04-15 22:47:52 -04:00
|
|
|
|
|
|
|
fail_free_image:
|
2020-02-17 12:44:37 +01:00
|
|
|
efi_free(image_size, image_addr);
|
2019-12-24 16:10:19 +01:00
|
|
|
efi_free(reserve_size, reserve_addr);
|
2016-01-26 14:48:29 +01:00
|
|
|
fail_free_cmdline:
|
2019-12-24 16:10:19 +01:00
|
|
|
free_screen_info(si);
|
|
|
|
efi_free(cmdline_size, (unsigned long)cmdline_ptr);
|
2014-04-15 22:47:52 -04:00
|
|
|
fail:
|
2020-02-17 12:44:37 +01:00
|
|
|
return status;
|
2014-04-15 22:47:52 -04:00
|
|
|
}
|
2014-10-20 16:27:26 +02: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-04 17:09:10 +01:00
|
|
|
u64 efi_virt_base = virtmap_base;
|
2020-02-10 19:29:36 +01:00
|
|
|
efi_memory_desc_t *in, *out = runtime_map;
|
2014-10-20 16:27:26 +02:00
|
|
|
int l;
|
|
|
|
|
2020-02-10 19:29:36 +01:00
|
|
|
for (l = 0; l < map_size; l += desc_size) {
|
2014-10-20 16:27:26 +02: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-25 23:02:19 +01:00
|
|
|
in = (void *)memory_map + l;
|
2014-10-20 16:27:26 +02: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-25 23:02:19 +01:00
|
|
|
paddr = in->phys_addr;
|
|
|
|
size = in->num_pages * EFI_PAGE_SIZE;
|
|
|
|
|
2020-02-10 19:29:36 +01:00
|
|
|
in->virt_addr = in->phys_addr;
|
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 10:41:16 +01:00
|
|
|
if (novamap()) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2014-10-20 16:27:26 +02: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-10 19:29:36 +01: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-25 23:02:19 +01: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 16:27:26 +02:00
|
|
|
|
2020-02-10 19:29:36 +01:00
|
|
|
in->virt_addr += efi_virt_base - paddr;
|
|
|
|
efi_virt_base += size;
|
|
|
|
}
|
2014-10-20 16:27:26 +02:00
|
|
|
|
|
|
|
memcpy(out, in, desc_size);
|
|
|
|
out = (void *)out + desc_size;
|
|
|
|
++*count;
|
|
|
|
}
|
|
|
|
}
|