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>
|
2024-12-19 10:37:40 +01:00
|
|
|
#include <linux/screen_info.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
|
2020-09-17 15:37:15 -07:00
|
|
|
* for UEFI Runtime Services.
|
|
|
|
*
|
|
|
|
* For ARM/ARM64:
|
|
|
|
* This is in the low TTBR0 range so that we can use
|
2017-04-04 17:09:10 +01:00
|
|
|
* 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)
|
2020-09-17 15:37:15 -07:00
|
|
|
*
|
|
|
|
* For RISC-V:
|
|
|
|
* There is no specific reason for which, this address (512MB) can't be used
|
|
|
|
* EFI runtime virtual address for RISC-V. It also helps to use EFI runtime
|
|
|
|
* services on both RV32/RV64. Keep the same runtime virtual address for RISC-V
|
|
|
|
* as well to minimize the code churn.
|
2017-04-04 17:09:10 +01:00
|
|
|
*/
|
|
|
|
#define EFI_RT_VIRTUAL_BASE SZ_512M
|
2017-04-17 10:32:01 +01:00
|
|
|
|
efi/loongarch: Add efistub booting support
This patch adds efistub booting support, which is the standard UEFI boot
protocol for LoongArch to use.
We use generic efistub, which means we can pass boot information (i.e.,
system table, memory map, kernel command line, initrd) via a light FDT
and drop a lot of non-standard code.
We use a flat mapping to map the efi runtime in the kernel's address
space. In efi, VA = PA; in kernel, VA = PA + PAGE_OFFSET. As a result,
flat mapping is not identity mapping, SetVirtualAddressMap() is still
needed for the efi runtime.
Tested-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
[ardb: change fpic to fpie as suggested by Xi Ruoyao]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-08-19 18:20:37 +08:00
|
|
|
/*
|
|
|
|
* Some architectures map the EFI regions into the kernel's linear map using a
|
|
|
|
* fixed offset.
|
|
|
|
*/
|
|
|
|
#ifndef EFI_RT_VIRTUAL_OFFSET
|
|
|
|
#define EFI_RT_VIRTUAL_OFFSET 0
|
|
|
|
#endif
|
|
|
|
|
2017-04-04 17:09:10 +01:00
|
|
|
static u64 virtmap_base = EFI_RT_VIRTUAL_BASE;
|
efi/loongarch: Add efistub booting support
This patch adds efistub booting support, which is the standard UEFI boot
protocol for LoongArch to use.
We use generic efistub, which means we can pass boot information (i.e.,
system table, memory map, kernel command line, initrd) via a light FDT
and drop a lot of non-standard code.
We use a flat mapping to map the efi runtime in the kernel's address
space. In efi, VA = PA; in kernel, VA = PA + PAGE_OFFSET. As a result,
flat mapping is not identity mapping, SetVirtualAddressMap() is still
needed for the efi runtime.
Tested-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
[ardb: change fpic to fpie as suggested by Xi Ruoyao]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-08-19 18:20:37 +08:00
|
|
|
static bool flat_va_mapping = (EFI_RT_VIRTUAL_OFFSET != 0);
|
2017-04-04 17:09:10 +01:00
|
|
|
|
2022-10-11 17:10:39 +02:00
|
|
|
void __weak free_screen_info(struct screen_info *si)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
static struct screen_info *setup_graphics(void)
|
2016-04-25 21:06:54 +01:00
|
|
|
{
|
2024-12-19 10:37:40 +01:00
|
|
|
struct screen_info *si, tmp = {};
|
|
|
|
|
|
|
|
if (efi_setup_gop(&tmp) != EFI_SUCCESS)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
si = alloc_screen_info();
|
|
|
|
if (!si)
|
|
|
|
return NULL;
|
2016-04-25 21:06:54 +01:00
|
|
|
|
2024-12-19 10:37:40 +01:00
|
|
|
*si = tmp;
|
2016-04-25 21:06:54 +01:00
|
|
|
return si;
|
|
|
|
}
|
2014-04-15 22:47:52 -04:00
|
|
|
|
2020-04-23 20:08:33 +08:00
|
|
|
static 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) {
|
2020-04-30 14:28:35 -04:00
|
|
|
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)
|
2020-04-30 14:28:35 -04:00
|
|
|
efi_err("Failed to install memreserve config table!\n");
|
2018-09-21 09:32:45 -07:00
|
|
|
}
|
|
|
|
|
2021-03-05 10:21:05 +01:00
|
|
|
static u32 get_supported_rt_services(void)
|
|
|
|
{
|
|
|
|
const efi_rt_properties_table_t *rt_prop_table;
|
|
|
|
u32 supported = EFI_RT_SUPPORTED_ALL;
|
|
|
|
|
|
|
|
rt_prop_table = get_efi_config_table(EFI_RT_PROPERTIES_TABLE_GUID);
|
|
|
|
if (rt_prop_table)
|
|
|
|
supported &= rt_prop_table->runtime_services_supported;
|
|
|
|
|
|
|
|
return supported;
|
|
|
|
}
|
|
|
|
|
2022-10-12 12:55:11 +02:00
|
|
|
efi_status_t efi_handle_cmdline(efi_loaded_image_t *image, char **cmdline_ptr)
|
2014-04-15 22:47:52 -04:00
|
|
|
{
|
2024-12-20 12:04:57 +01:00
|
|
|
char *cmdline __free(efi_pool) = NULL;
|
2022-10-12 12:55:11 +02:00
|
|
|
efi_status_t status;
|
2014-04-15 22:47:52 -04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
2024-10-13 01:11:57 -04:00
|
|
|
cmdline = efi_convert_cmdline(image);
|
2022-10-12 12:55:11 +02:00
|
|
|
if (!cmdline) {
|
2020-04-30 14:28:35 -04:00
|
|
|
efi_err("getting command line via LOADED_IMAGE_PROTOCOL\n");
|
2022-10-12 12:55:11 +02:00
|
|
|
return EFI_OUT_OF_RESOURCES;
|
2016-01-26 14:48:29 +01:00
|
|
|
}
|
|
|
|
|
2024-10-13 15:50:03 +02:00
|
|
|
if (!IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
|
|
|
|
status = efi_parse_options(cmdline);
|
2024-12-20 12:04:57 +01:00
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
efi_err("Failed to parse EFI load options\n");
|
|
|
|
return status;
|
|
|
|
}
|
2024-10-13 15:50:03 +02:00
|
|
|
}
|
|
|
|
|
2017-04-04 17:09:09 +01:00
|
|
|
if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
|
|
|
|
IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
|
2024-10-13 01:11:56 -04:00
|
|
|
cmdline[0] == 0) {
|
2020-04-30 14:28:43 -04:00
|
|
|
status = efi_parse_options(CONFIG_CMDLINE);
|
2024-12-20 12:04:57 +01:00
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
efi_err("Failed to parse built-in command line\n");
|
|
|
|
return status;
|
|
|
|
}
|
2020-04-30 14:28:43 -04:00
|
|
|
}
|
2017-04-04 17:09:09 +01:00
|
|
|
|
2024-12-20 12:04:57 +01:00
|
|
|
*cmdline_ptr = no_free_ptr(cmdline);
|
2022-10-12 12:55:11 +02:00
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
2016-04-25 21:06:54 +01:00
|
|
|
|
2022-10-12 12:55:11 +02:00
|
|
|
efi_status_t efi_stub_common(efi_handle_t handle,
|
|
|
|
efi_loaded_image_t *image,
|
|
|
|
unsigned long image_addr,
|
|
|
|
char *cmdline_ptr)
|
|
|
|
{
|
|
|
|
struct screen_info *si;
|
|
|
|
efi_status_t status;
|
|
|
|
|
|
|
|
status = check_platform_features();
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
si = setup_graphics();
|
2014-04-15 22:47:52 -04:00
|
|
|
|
2024-02-15 03:00:02 +00:00
|
|
|
efi_retrieve_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
|
|
|
|
2022-09-16 14:03:06 +02:00
|
|
|
efi_load_initrd(image, ULONG_MAX, efi_get_max_initrd_addr(image_addr),
|
|
|
|
NULL);
|
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
|
|
|
|
2021-03-05 10:21:05 +01:00
|
|
|
/* force efi_novamap if SetVirtualAddressMap() is unsupported */
|
|
|
|
efi_novamap |= !(get_supported_rt_services() &
|
|
|
|
EFI_RT_SUPPORTED_SET_VIRTUAL_ADDRESS_MAP);
|
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
install_memreserve_table();
|
2018-09-21 09:32:45 -07:00
|
|
|
|
2022-09-16 18:51:36 +02:00
|
|
|
status = efi_boot_kernel(handle, image, image_addr, cmdline_ptr);
|
2014-04-15 22:47:52 -04:00
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
free_screen_info(si);
|
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
|
|
|
|
2022-09-15 19:45:35 +02:00
|
|
|
/*
|
|
|
|
* efi_allocate_virtmap() - create a pool allocation for the virtmap
|
|
|
|
*
|
|
|
|
* Create an allocation that is of sufficient size to hold all the memory
|
|
|
|
* descriptors that will be passed to SetVirtualAddressMap() to inform the
|
|
|
|
* firmware about the virtual mapping that will be used under the OS to call
|
|
|
|
* into the firmware.
|
|
|
|
*/
|
|
|
|
efi_status_t efi_alloc_virtmap(efi_memory_desc_t **virtmap,
|
|
|
|
unsigned long *desc_size, u32 *desc_ver)
|
|
|
|
{
|
|
|
|
unsigned long size, mmap_key;
|
|
|
|
efi_status_t status;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Use the size of the current memory map as an upper bound for the
|
|
|
|
* size of the buffer we need to pass to SetVirtualAddressMap() to
|
|
|
|
* cover all EFI_MEMORY_RUNTIME regions.
|
|
|
|
*/
|
|
|
|
size = 0;
|
|
|
|
status = efi_bs_call(get_memory_map, &size, NULL, &mmap_key, desc_size,
|
|
|
|
desc_ver);
|
|
|
|
if (status != EFI_BUFFER_TOO_SMALL)
|
|
|
|
return EFI_LOAD_ERROR;
|
|
|
|
|
|
|
|
return efi_bs_call(allocate_pool, EFI_LOADER_DATA, size,
|
|
|
|
(void **)virtmap);
|
|
|
|
}
|
|
|
|
|
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;
|
|
|
|
|
2022-09-15 19:45:35 +02:00
|
|
|
*count = 0;
|
|
|
|
|
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;
|
|
|
|
|
efi/loongarch: Add efistub booting support
This patch adds efistub booting support, which is the standard UEFI boot
protocol for LoongArch to use.
We use generic efistub, which means we can pass boot information (i.e.,
system table, memory map, kernel command line, initrd) via a light FDT
and drop a lot of non-standard code.
We use a flat mapping to map the efi runtime in the kernel's address
space. In efi, VA = PA; in kernel, VA = PA + PAGE_OFFSET. As a result,
flat mapping is not identity mapping, SetVirtualAddressMap() is still
needed for the efi runtime.
Tested-by: Xi Ruoyao <xry111@xry111.site>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
[ardb: change fpic to fpie as suggested by Xi Ruoyao]
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-08-19 18:20:37 +08:00
|
|
|
in->virt_addr = in->phys_addr + EFI_RT_VIRTUAL_OFFSET;
|
2020-04-16 18:45:24 +02: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 10:41:16 +01:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
}
|