2019-02-02 10:41:15 +01:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2013-09-22 15:45:27 -07:00
|
|
|
/*
|
|
|
|
* Helper functions used by the EFI stub on multiple
|
|
|
|
* architectures. This should be #included by the EFI stub
|
|
|
|
* implementation files.
|
|
|
|
*
|
|
|
|
* Copyright 2011 Intel Corporation; author Matt Fleming
|
|
|
|
*/
|
|
|
|
|
2021-08-02 23:40:32 +03:00
|
|
|
#include <linux/stdarg.h>
|
2020-05-18 15:06:56 -04:00
|
|
|
|
2014-07-02 14:54:42 +02:00
|
|
|
#include <linux/efi.h>
|
2020-05-18 15:06:55 -04:00
|
|
|
#include <linux/kernel.h>
|
2024-03-08 09:17:07 +01:00
|
|
|
#include <linux/overflow.h>
|
2014-07-02 14:54:42 +02:00
|
|
|
#include <asm/efi.h>
|
2020-05-20 20:29:21 -04:00
|
|
|
#include <asm/setup.h>
|
2014-07-02 14:54:42 +02:00
|
|
|
|
|
|
|
#include "efistub.h"
|
2014-01-28 10:41:28 -08:00
|
|
|
|
2020-04-16 18:45:24 +02:00
|
|
|
bool efi_nochunk;
|
2020-07-09 21:48:41 +01:00
|
|
|
bool efi_nokaslr = !IS_ENABLED(CONFIG_RANDOMIZE_BASE);
|
2020-04-16 18:45:24 +02:00
|
|
|
bool efi_novamap;
|
|
|
|
|
2021-11-19 13:47:44 +02:00
|
|
|
static bool efi_noinitrd;
|
2020-04-16 11:12:27 -04:00
|
|
|
static bool efi_nosoftreserve;
|
|
|
|
static bool efi_disable_pci_dma = IS_ENABLED(CONFIG_EFI_DISABLE_PCI_DMA);
|
2017-04-04 17:09:08 +01:00
|
|
|
|
2024-02-27 16:19:13 +01:00
|
|
|
int efi_mem_encrypt;
|
|
|
|
|
2019-11-06 17:43:11 -08:00
|
|
|
bool __pure __efi_soft_reserve_enabled(void)
|
|
|
|
{
|
|
|
|
return !efi_nosoftreserve;
|
|
|
|
}
|
2017-04-04 17:09:08 +01:00
|
|
|
|
2020-06-16 01:42:31 +02:00
|
|
|
/**
|
|
|
|
* efi_parse_options() - Parse EFI command line options
|
|
|
|
* @cmdline: kernel command line
|
|
|
|
*
|
|
|
|
* Parse the ASCII string @cmdline for EFI options, denoted by the efi=
|
2014-08-05 11:52:11 +01:00
|
|
|
* option, e.g. efi=nochunk.
|
|
|
|
*
|
|
|
|
* It should be noted that efi= is parsed in two very different
|
|
|
|
* environments, first in the early boot environment of the EFI boot
|
|
|
|
* stub, and subsequently during the kernel boot.
|
2020-06-16 01:42:31 +02:00
|
|
|
*
|
|
|
|
* Return: status code
|
2014-08-05 11:52:11 +01:00
|
|
|
*/
|
2017-04-04 17:09:08 +01:00
|
|
|
efi_status_t efi_parse_options(char const *cmdline)
|
2014-08-05 11:52:11 +01:00
|
|
|
{
|
2024-12-20 12:04:57 +01:00
|
|
|
char *buf __free(efi_pool) = NULL;
|
efi/libstub: Clean up command line parsing routine
We currently parse the command non-destructively, to avoid having to
allocate memory for a copy before passing it to the standard parsing
routines that are used by the core kernel, and which modify the input
to delineate the parsed tokens with NUL characters.
Instead, we call strstr() and strncmp() to go over the input multiple
times, and match prefixes rather than tokens, which implies that we
would match, e.g., 'nokaslrfoo' in the stub and disable KASLR, while
the kernel would disregard the option and run with KASLR enabled.
In order to avoid having to reason about whether and how this behavior
may be abused, let's clean up the parsing routines, and rebuild them
on top of the existing helpers.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-10 17:02:46 +01:00
|
|
|
efi_status_t status;
|
2024-12-20 12:04:57 +01:00
|
|
|
size_t len;
|
|
|
|
char *str;
|
2014-08-05 11:52:11 +01:00
|
|
|
|
2020-07-29 15:33:00 -04:00
|
|
|
if (!cmdline)
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
|
2020-08-13 14:58:11 -04:00
|
|
|
len = strnlen(cmdline, COMMAND_LINE_SIZE - 1) + 1;
|
efi/libstub: Clean up command line parsing routine
We currently parse the command non-destructively, to avoid having to
allocate memory for a copy before passing it to the standard parsing
routines that are used by the core kernel, and which modify the input
to delineate the parsed tokens with NUL characters.
Instead, we call strstr() and strncmp() to go over the input multiple
times, and match prefixes rather than tokens, which implies that we
would match, e.g., 'nokaslrfoo' in the stub and disable KASLR, while
the kernel would disregard the option and run with KASLR enabled.
In order to avoid having to reason about whether and how this behavior
may be abused, let's clean up the parsing routines, and rebuild them
on top of the existing helpers.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-10 17:02:46 +01:00
|
|
|
status = efi_bs_call(allocate_pool, EFI_LOADER_DATA, len, (void **)&buf);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
return status;
|
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
|
|
|
|
2020-08-13 14:58:11 -04:00
|
|
|
memcpy(buf, cmdline, len - 1);
|
|
|
|
buf[len - 1] = '\0';
|
|
|
|
str = skip_spaces(buf);
|
2019-11-06 17:43:11 -08:00
|
|
|
|
efi/libstub: Clean up command line parsing routine
We currently parse the command non-destructively, to avoid having to
allocate memory for a copy before passing it to the standard parsing
routines that are used by the core kernel, and which modify the input
to delineate the parsed tokens with NUL characters.
Instead, we call strstr() and strncmp() to go over the input multiple
times, and match prefixes rather than tokens, which implies that we
would match, e.g., 'nokaslrfoo' in the stub and disable KASLR, while
the kernel would disregard the option and run with KASLR enabled.
In order to avoid having to reason about whether and how this behavior
may be abused, let's clean up the parsing routines, and rebuild them
on top of the existing helpers.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-10 17:02:46 +01:00
|
|
|
while (*str) {
|
|
|
|
char *param, *val;
|
2020-01-03 12:39:50 +01:00
|
|
|
|
efi/libstub: Clean up command line parsing routine
We currently parse the command non-destructively, to avoid having to
allocate memory for a copy before passing it to the standard parsing
routines that are used by the core kernel, and which modify the input
to delineate the parsed tokens with NUL characters.
Instead, we call strstr() and strncmp() to go over the input multiple
times, and match prefixes rather than tokens, which implies that we
would match, e.g., 'nokaslrfoo' in the stub and disable KASLR, while
the kernel would disregard the option and run with KASLR enabled.
In order to avoid having to reason about whether and how this behavior
may be abused, let's clean up the parsing routines, and rebuild them
on top of the existing helpers.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-10 17:02:46 +01:00
|
|
|
str = next_arg(str, ¶m, &val);
|
2020-07-25 11:59:16 -04:00
|
|
|
if (!val && !strcmp(param, "--"))
|
|
|
|
break;
|
2020-01-03 12:39:50 +01:00
|
|
|
|
efi/libstub: Clean up command line parsing routine
We currently parse the command non-destructively, to avoid having to
allocate memory for a copy before passing it to the standard parsing
routines that are used by the core kernel, and which modify the input
to delineate the parsed tokens with NUL characters.
Instead, we call strstr() and strncmp() to go over the input multiple
times, and match prefixes rather than tokens, which implies that we
would match, e.g., 'nokaslrfoo' in the stub and disable KASLR, while
the kernel would disregard the option and run with KASLR enabled.
In order to avoid having to reason about whether and how this behavior
may be abused, let's clean up the parsing routines, and rebuild them
on top of the existing helpers.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-10 17:02:46 +01:00
|
|
|
if (!strcmp(param, "nokaslr")) {
|
|
|
|
efi_nokaslr = true;
|
|
|
|
} else if (!strcmp(param, "quiet")) {
|
2020-05-20 19:07:54 +02:00
|
|
|
efi_loglevel = CONSOLE_LOGLEVEL_QUIET;
|
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-04 22:01:22 +00:00
|
|
|
} else if (!strcmp(param, "noinitrd")) {
|
|
|
|
efi_noinitrd = true;
|
2023-08-07 18:27:13 +02:00
|
|
|
} else if (IS_ENABLED(CONFIG_X86_64) && !strcmp(param, "no5lvl")) {
|
|
|
|
efi_no5lvl = true;
|
2024-02-27 16:19:13 +01:00
|
|
|
} else if (IS_ENABLED(CONFIG_ARCH_HAS_MEM_ENCRYPT) &&
|
|
|
|
!strcmp(param, "mem_encrypt") && val) {
|
|
|
|
if (parse_option_str(val, "on"))
|
|
|
|
efi_mem_encrypt = 1;
|
|
|
|
else if (parse_option_str(val, "off"))
|
|
|
|
efi_mem_encrypt = -1;
|
efi/libstub: Clean up command line parsing routine
We currently parse the command non-destructively, to avoid having to
allocate memory for a copy before passing it to the standard parsing
routines that are used by the core kernel, and which modify the input
to delineate the parsed tokens with NUL characters.
Instead, we call strstr() and strncmp() to go over the input multiple
times, and match prefixes rather than tokens, which implies that we
would match, e.g., 'nokaslrfoo' in the stub and disable KASLR, while
the kernel would disregard the option and run with KASLR enabled.
In order to avoid having to reason about whether and how this behavior
may be abused, let's clean up the parsing routines, and rebuild them
on top of the existing helpers.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-10 17:02:46 +01:00
|
|
|
} else if (!strcmp(param, "efi") && val) {
|
|
|
|
efi_nochunk = parse_option_str(val, "nochunk");
|
efi/arm64: libstub: avoid SetVirtualAddressMap() when possible
EFI's SetVirtualAddressMap() runtime service is a horrid hack that we'd
like to avoid using, if possible. For 64-bit architectures such as
arm64, the user and kernel mappings are entirely disjoint, and given
that we use the user region for mapping the UEFI runtime regions when
running under the OS, we don't rely on SetVirtualAddressMap() in the
conventional way, i.e., to permit kernel mappings of the OS to coexist
with kernel region mappings of the firmware regions. This means that, in
principle, we should be able to avoid SetVirtualAddressMap() altogether,
and simply use the 1:1 mapping that UEFI uses at boot time. (Note that
omitting SetVirtualAddressMap() is explicitly permitted by the UEFI
spec).
However, there is a corner case on arm64, which, if configured for
3-level paging (or 2-level paging when using 64k pages), may not be able
to cover the entire range of firmware mappings (which might contain both
memory and MMIO peripheral mappings).
So let's avoid SetVirtualAddressMap() on arm64, but only if the VA space
is guaranteed to be of sufficient size.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-09-16 11:48:30 +02:00
|
|
|
efi_novamap |= parse_option_str(val, "novamap");
|
2014-08-05 11:52:11 +01:00
|
|
|
|
efi/libstub: Clean up command line parsing routine
We currently parse the command non-destructively, to avoid having to
allocate memory for a copy before passing it to the standard parsing
routines that are used by the core kernel, and which modify the input
to delineate the parsed tokens with NUL characters.
Instead, we call strstr() and strncmp() to go over the input multiple
times, and match prefixes rather than tokens, which implies that we
would match, e.g., 'nokaslrfoo' in the stub and disable KASLR, while
the kernel would disregard the option and run with KASLR enabled.
In order to avoid having to reason about whether and how this behavior
may be abused, let's clean up the parsing routines, and rebuild them
on top of the existing helpers.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-10 17:02:46 +01:00
|
|
|
efi_nosoftreserve = IS_ENABLED(CONFIG_EFI_SOFT_RESERVE) &&
|
|
|
|
parse_option_str(val, "nosoftreserve");
|
2014-08-05 11:52:11 +01:00
|
|
|
|
efi/libstub: Clean up command line parsing routine
We currently parse the command non-destructively, to avoid having to
allocate memory for a copy before passing it to the standard parsing
routines that are used by the core kernel, and which modify the input
to delineate the parsed tokens with NUL characters.
Instead, we call strstr() and strncmp() to go over the input multiple
times, and match prefixes rather than tokens, which implies that we
would match, e.g., 'nokaslrfoo' in the stub and disable KASLR, while
the kernel would disregard the option and run with KASLR enabled.
In order to avoid having to reason about whether and how this behavior
may be abused, let's clean up the parsing routines, and rebuild them
on top of the existing helpers.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-10 17:02:46 +01:00
|
|
|
if (parse_option_str(val, "disable_early_pci_dma"))
|
|
|
|
efi_disable_pci_dma = true;
|
|
|
|
if (parse_option_str(val, "no_disable_early_pci_dma"))
|
|
|
|
efi_disable_pci_dma = false;
|
2020-05-20 19:07:54 +02:00
|
|
|
if (parse_option_str(val, "debug"))
|
|
|
|
efi_loglevel = CONSOLE_LOGLEVEL_DEBUG;
|
2020-03-19 22:00:25 -04:00
|
|
|
} else if (!strcmp(param, "video") &&
|
|
|
|
val && strstarts(val, "efifb:")) {
|
|
|
|
efi_parse_option_graphics(val + strlen("efifb:"));
|
efi/libstub: Clean up command line parsing routine
We currently parse the command non-destructively, to avoid having to
allocate memory for a copy before passing it to the standard parsing
routines that are used by the core kernel, and which modify the input
to delineate the parsed tokens with NUL characters.
Instead, we call strstr() and strncmp() to go over the input multiple
times, and match prefixes rather than tokens, which implies that we
would match, e.g., 'nokaslrfoo' in the stub and disable KASLR, while
the kernel would disregard the option and run with KASLR enabled.
In order to avoid having to reason about whether and how this behavior
may be abused, let's clean up the parsing routines, and rebuild them
on top of the existing helpers.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-02-10 17:02:46 +01:00
|
|
|
}
|
|
|
|
}
|
2014-08-05 11:52:11 +01:00
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
2013-09-22 15:45:27 -07:00
|
|
|
|
2020-09-14 17:35:35 -04:00
|
|
|
/*
|
|
|
|
* The EFI_LOAD_OPTION descriptor has the following layout:
|
|
|
|
* u32 Attributes;
|
|
|
|
* u16 FilePathListLength;
|
|
|
|
* u16 Description[];
|
|
|
|
* efi_device_path_protocol_t FilePathList[];
|
|
|
|
* u8 OptionalData[];
|
|
|
|
*
|
|
|
|
* This function validates and unpacks the variable-size data fields.
|
|
|
|
*/
|
|
|
|
static
|
|
|
|
bool efi_load_option_unpack(efi_load_option_unpacked_t *dest,
|
|
|
|
const efi_load_option_t *src, size_t size)
|
|
|
|
{
|
|
|
|
const void *pos;
|
|
|
|
u16 c;
|
|
|
|
efi_device_path_protocol_t header;
|
|
|
|
const efi_char16_t *description;
|
|
|
|
const efi_device_path_protocol_t *file_path_list;
|
|
|
|
|
|
|
|
if (size < offsetof(efi_load_option_t, variable_data))
|
|
|
|
return false;
|
|
|
|
pos = src->variable_data;
|
|
|
|
size -= offsetof(efi_load_option_t, variable_data);
|
|
|
|
|
|
|
|
if ((src->attributes & ~EFI_LOAD_OPTION_MASK) != 0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Scan description. */
|
|
|
|
description = pos;
|
|
|
|
do {
|
|
|
|
if (size < sizeof(c))
|
|
|
|
return false;
|
|
|
|
c = *(const u16 *)pos;
|
|
|
|
pos += sizeof(c);
|
|
|
|
size -= sizeof(c);
|
|
|
|
} while (c != L'\0');
|
|
|
|
|
|
|
|
/* Scan file_path_list. */
|
|
|
|
file_path_list = pos;
|
|
|
|
do {
|
|
|
|
if (size < sizeof(header))
|
|
|
|
return false;
|
|
|
|
header = *(const efi_device_path_protocol_t *)pos;
|
|
|
|
if (header.length < sizeof(header))
|
|
|
|
return false;
|
|
|
|
if (size < header.length)
|
|
|
|
return false;
|
|
|
|
pos += header.length;
|
|
|
|
size -= header.length;
|
|
|
|
} while ((header.type != EFI_DEV_END_PATH && header.type != EFI_DEV_END_PATH2) ||
|
|
|
|
(header.sub_type != EFI_DEV_END_ENTIRE));
|
|
|
|
if (pos != (const void *)file_path_list + src->file_path_list_length)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
dest->attributes = src->attributes;
|
|
|
|
dest->file_path_list_length = src->file_path_list_length;
|
|
|
|
dest->description = description;
|
|
|
|
dest->file_path_list = file_path_list;
|
|
|
|
dest->optional_data_size = size;
|
|
|
|
dest->optional_data = size ? pos : NULL;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* At least some versions of Dell firmware pass the entire contents of the
|
|
|
|
* Boot#### variable, i.e. the EFI_LOAD_OPTION descriptor, rather than just the
|
|
|
|
* OptionalData field.
|
|
|
|
*
|
|
|
|
* Detect this case and extract OptionalData.
|
|
|
|
*/
|
2022-09-14 16:14:18 +02:00
|
|
|
void efi_apply_loadoptions_quirk(const void **load_options, u32 *load_options_size)
|
2020-09-14 17:35:35 -04:00
|
|
|
{
|
|
|
|
const efi_load_option_t *load_option = *load_options;
|
|
|
|
efi_load_option_unpacked_t load_option_unpacked;
|
|
|
|
|
|
|
|
if (!IS_ENABLED(CONFIG_X86))
|
|
|
|
return;
|
|
|
|
if (!load_option)
|
|
|
|
return;
|
|
|
|
if (*load_options_size < sizeof(*load_option))
|
|
|
|
return;
|
|
|
|
if ((load_option->attributes & ~EFI_LOAD_OPTION_BOOT_MASK) != 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (!efi_load_option_unpack(&load_option_unpacked, load_option, *load_options_size))
|
|
|
|
return;
|
|
|
|
|
|
|
|
efi_warn_once(FW_BUG "LoadOptions is an EFI_LOAD_OPTION descriptor\n");
|
|
|
|
efi_warn_once(FW_BUG "Using OptionalData as a workaround\n");
|
|
|
|
|
|
|
|
*load_options = load_option_unpacked.optional_data;
|
|
|
|
*load_options_size = load_option_unpacked.optional_data_size;
|
|
|
|
}
|
|
|
|
|
2024-03-04 10:40:24 +01:00
|
|
|
enum efistub_event_type {
|
2022-09-16 11:14:34 +03:00
|
|
|
EFISTUB_EVT_INITRD,
|
efi/libstub: measure EFI LoadOptions
The EFI TCG spec, in §10.2.6 "Measuring UEFI Variables and UEFI GPT
Data", only reasons about the load options passed to a loaded image in
the context of boot options booted directly from the BDS, which are
measured into PCR #5 along with the rest of the Boot#### EFI variable.
However, the UEFI spec mentions the following in the documentation of
the LoadImage() boot service and the EFI_LOADED_IMAGE protocol:
The caller may fill in the image’s "load options" data, or add
additional protocol support to the handle before passing control to
the newly loaded image by calling EFI_BOOT_SERVICES.StartImage().
The typical boot sequence for Linux EFI systems is to load GRUB via a
boot option from the BDS, which [hopefully] calls LoadImage to load the
kernel image, passing the kernel command line via the mechanism
described above. This means that we cannot rely on the firmware
implementing TCG measured boot to ensure that the kernel command line
gets measured before the image is started, so the EFI stub will have to
take care of this itself.
Given that PCR #5 has an official use in the TCG measured boot spec,
let's avoid it in this case. Instead, add a measurement in PCR #9 (which
we already use for our initrd) and extend it with the LoadOptions
measurements
Co-developed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-09-16 11:14:35 +03:00
|
|
|
EFISTUB_EVT_LOAD_OPTIONS,
|
2022-09-16 11:14:34 +03:00
|
|
|
EFISTUB_EVT_COUNT,
|
|
|
|
};
|
|
|
|
|
|
|
|
#define STR_WITH_SIZE(s) sizeof(s), s
|
|
|
|
|
|
|
|
static const struct {
|
|
|
|
u32 pcr_index;
|
|
|
|
u32 event_id;
|
|
|
|
u32 event_data_len;
|
|
|
|
u8 event_data[52];
|
|
|
|
} events[] = {
|
|
|
|
[EFISTUB_EVT_INITRD] = {
|
|
|
|
9,
|
|
|
|
INITRD_EVENT_TAG_ID,
|
|
|
|
STR_WITH_SIZE("Linux initrd")
|
|
|
|
},
|
efi/libstub: measure EFI LoadOptions
The EFI TCG spec, in §10.2.6 "Measuring UEFI Variables and UEFI GPT
Data", only reasons about the load options passed to a loaded image in
the context of boot options booted directly from the BDS, which are
measured into PCR #5 along with the rest of the Boot#### EFI variable.
However, the UEFI spec mentions the following in the documentation of
the LoadImage() boot service and the EFI_LOADED_IMAGE protocol:
The caller may fill in the image’s "load options" data, or add
additional protocol support to the handle before passing control to
the newly loaded image by calling EFI_BOOT_SERVICES.StartImage().
The typical boot sequence for Linux EFI systems is to load GRUB via a
boot option from the BDS, which [hopefully] calls LoadImage to load the
kernel image, passing the kernel command line via the mechanism
described above. This means that we cannot rely on the firmware
implementing TCG measured boot to ensure that the kernel command line
gets measured before the image is started, so the EFI stub will have to
take care of this itself.
Given that PCR #5 has an official use in the TCG measured boot spec,
let's avoid it in this case. Instead, add a measurement in PCR #9 (which
we already use for our initrd) and extend it with the LoadOptions
measurements
Co-developed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-09-16 11:14:35 +03:00
|
|
|
[EFISTUB_EVT_LOAD_OPTIONS] = {
|
|
|
|
9,
|
|
|
|
LOAD_OPTIONS_EVENT_TAG_ID,
|
|
|
|
STR_WITH_SIZE("LOADED_IMAGE::LoadOptions")
|
|
|
|
},
|
2022-09-16 11:14:34 +03:00
|
|
|
};
|
|
|
|
|
2024-03-04 10:40:24 +01:00
|
|
|
static_assert(sizeof(efi_tcg2_event_t) == sizeof(efi_cc_event_t));
|
|
|
|
|
|
|
|
union efistub_event {
|
|
|
|
efi_tcg2_event_t tcg2_data;
|
|
|
|
efi_cc_event_t cc_data;
|
|
|
|
};
|
|
|
|
|
2024-03-08 09:17:07 +01:00
|
|
|
struct efistub_measured_event {
|
2024-03-04 10:40:24 +01:00
|
|
|
union efistub_event event_data;
|
2024-03-08 09:17:07 +01:00
|
|
|
TCG_PCClientTaggedEvent tagged_event __packed;
|
|
|
|
};
|
|
|
|
|
2022-09-16 11:14:34 +03:00
|
|
|
static efi_status_t efi_measure_tagged_event(unsigned long load_addr,
|
|
|
|
unsigned long load_size,
|
2024-03-04 10:40:24 +01:00
|
|
|
enum efistub_event_type event)
|
2022-09-16 11:14:34 +03:00
|
|
|
{
|
2024-03-04 10:40:24 +01:00
|
|
|
union {
|
|
|
|
efi_status_t
|
|
|
|
(__efiapi *hash_log_extend_event)(void *, u64, efi_physical_addr_t,
|
|
|
|
u64, const union efistub_event *);
|
|
|
|
struct { u32 hash_log_extend_event; } mixed_mode;
|
|
|
|
} method;
|
2024-12-20 12:04:57 +01:00
|
|
|
struct efistub_measured_event *evt __free(efi_pool) = NULL;
|
2024-03-08 09:17:07 +01:00
|
|
|
int size = struct_size(evt, tagged_event.tagged_event_data,
|
|
|
|
events[event].event_data_len);
|
2022-09-16 11:14:34 +03:00
|
|
|
efi_guid_t tcg2_guid = EFI_TCG2_PROTOCOL_GUID;
|
|
|
|
efi_tcg2_protocol_t *tcg2 = NULL;
|
2024-03-04 10:40:24 +01:00
|
|
|
union efistub_event ev;
|
2022-09-16 11:14:34 +03:00
|
|
|
efi_status_t status;
|
2024-03-04 10:40:24 +01:00
|
|
|
void *protocol;
|
2022-09-16 11:14:34 +03:00
|
|
|
|
|
|
|
efi_bs_call(locate_protocol, &tcg2_guid, NULL, (void **)&tcg2);
|
|
|
|
if (tcg2) {
|
2024-03-04 10:40:24 +01:00
|
|
|
ev.tcg2_data = (struct efi_tcg2_event){
|
2022-09-16 11:14:34 +03:00
|
|
|
.event_size = size,
|
2024-03-04 10:40:24 +01:00
|
|
|
.event_header.header_size = sizeof(ev.tcg2_data.event_header),
|
2022-09-16 11:14:34 +03:00
|
|
|
.event_header.header_version = EFI_TCG2_EVENT_HEADER_VERSION,
|
|
|
|
.event_header.pcr_index = events[event].pcr_index,
|
|
|
|
.event_header.event_type = EV_EVENT_TAG,
|
|
|
|
};
|
2024-03-04 10:40:24 +01:00
|
|
|
protocol = tcg2;
|
|
|
|
method.hash_log_extend_event =
|
|
|
|
(void *)efi_table_attr(tcg2, hash_log_extend_event);
|
|
|
|
} else {
|
|
|
|
efi_guid_t cc_guid = EFI_CC_MEASUREMENT_PROTOCOL_GUID;
|
|
|
|
efi_cc_protocol_t *cc = NULL;
|
|
|
|
|
|
|
|
efi_bs_call(locate_protocol, &cc_guid, NULL, (void **)&cc);
|
|
|
|
if (!cc)
|
|
|
|
return EFI_UNSUPPORTED;
|
|
|
|
|
|
|
|
ev.cc_data = (struct efi_cc_event){
|
|
|
|
.event_size = size,
|
|
|
|
.event_header.header_size = sizeof(ev.cc_data.event_header),
|
|
|
|
.event_header.header_version = EFI_CC_EVENT_HEADER_VERSION,
|
|
|
|
.event_header.event_type = EV_EVENT_TAG,
|
2022-09-16 11:14:34 +03:00
|
|
|
};
|
|
|
|
|
2024-03-04 10:40:24 +01:00
|
|
|
status = efi_call_proto(cc, map_pcr_to_mr_index,
|
|
|
|
events[event].pcr_index,
|
|
|
|
&ev.cc_data.event_header.mr_index);
|
2022-09-16 11:14:34 +03:00
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
goto fail;
|
2024-03-04 10:40:24 +01:00
|
|
|
|
|
|
|
protocol = cc;
|
|
|
|
method.hash_log_extend_event =
|
|
|
|
(void *)efi_table_attr(cc, hash_log_extend_event);
|
2022-09-16 11:14:34 +03:00
|
|
|
}
|
|
|
|
|
2024-03-04 10:40:24 +01:00
|
|
|
status = efi_bs_call(allocate_pool, EFI_LOADER_DATA, size, (void **)&evt);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
*evt = (struct efistub_measured_event) {
|
|
|
|
.event_data = ev,
|
|
|
|
.tagged_event.tagged_event_id = events[event].event_id,
|
|
|
|
.tagged_event.tagged_event_data_size = events[event].event_data_len,
|
|
|
|
};
|
|
|
|
|
|
|
|
memcpy(evt->tagged_event.tagged_event_data, events[event].event_data,
|
|
|
|
events[event].event_data_len);
|
|
|
|
|
|
|
|
status = efi_fn_call(&method, hash_log_extend_event, protocol, 0,
|
|
|
|
load_addr, load_size, &evt->event_data);
|
|
|
|
|
|
|
|
if (status == EFI_SUCCESS)
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
|
2022-09-16 11:14:34 +03:00
|
|
|
fail:
|
|
|
|
efi_warn("Failed to measure data for event %d: 0x%lx\n", event, status);
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2013-09-22 15:45:33 -07:00
|
|
|
/*
|
|
|
|
* Convert the unicode UEFI command line to ASCII to pass to kernel.
|
|
|
|
* Size of memory allocated return in *cmd_line_len.
|
|
|
|
* Returns NULL on error.
|
|
|
|
*/
|
2024-10-13 01:11:57 -04:00
|
|
|
char *efi_convert_cmdline(efi_loaded_image_t *image)
|
2013-09-22 15:45:33 -07:00
|
|
|
{
|
2022-09-14 16:14:18 +02:00
|
|
|
const efi_char16_t *options = efi_table_attr(image, load_options);
|
|
|
|
u32 options_size = efi_table_attr(image, load_options_size);
|
2020-05-20 20:29:21 -04:00
|
|
|
int options_bytes = 0, safe_options_bytes = 0; /* UTF-8 bytes */
|
2022-09-14 16:14:18 +02:00
|
|
|
unsigned long cmdline_addr = 0;
|
|
|
|
const efi_char16_t *s2;
|
2020-05-20 20:29:21 -04:00
|
|
|
bool in_quote = false;
|
2013-09-22 15:45:33 -07:00
|
|
|
efi_status_t status;
|
2022-09-14 16:14:18 +02:00
|
|
|
u32 options_chars;
|
2013-09-22 15:45:33 -07:00
|
|
|
|
efi/libstub: measure EFI LoadOptions
The EFI TCG spec, in §10.2.6 "Measuring UEFI Variables and UEFI GPT
Data", only reasons about the load options passed to a loaded image in
the context of boot options booted directly from the BDS, which are
measured into PCR #5 along with the rest of the Boot#### EFI variable.
However, the UEFI spec mentions the following in the documentation of
the LoadImage() boot service and the EFI_LOADED_IMAGE protocol:
The caller may fill in the image’s "load options" data, or add
additional protocol support to the handle before passing control to
the newly loaded image by calling EFI_BOOT_SERVICES.StartImage().
The typical boot sequence for Linux EFI systems is to load GRUB via a
boot option from the BDS, which [hopefully] calls LoadImage to load the
kernel image, passing the kernel command line via the mechanism
described above. This means that we cannot rely on the firmware
implementing TCG measured boot to ensure that the kernel command line
gets measured before the image is started, so the EFI stub will have to
take care of this itself.
Given that PCR #5 has an official use in the TCG measured boot spec,
let's avoid it in this case. Instead, add a measurement in PCR #9 (which
we already use for our initrd) and extend it with the LoadOptions
measurements
Co-developed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2022-09-16 11:14:35 +03:00
|
|
|
if (options_size > 0)
|
|
|
|
efi_measure_tagged_event((unsigned long)options, options_size,
|
|
|
|
EFISTUB_EVT_LOAD_OPTIONS);
|
|
|
|
|
2022-09-14 16:14:18 +02:00
|
|
|
efi_apply_loadoptions_quirk((const void **)&options, &options_size);
|
|
|
|
options_chars = options_size / sizeof(efi_char16_t);
|
2020-09-14 17:35:35 -04:00
|
|
|
|
2013-09-22 15:45:33 -07:00
|
|
|
if (options) {
|
|
|
|
s2 = options;
|
2020-05-20 20:29:21 -04:00
|
|
|
while (options_bytes < COMMAND_LINE_SIZE && options_chars--) {
|
2022-09-14 16:14:18 +02:00
|
|
|
efi_char16_t c = *s2++;
|
2020-05-18 15:07:15 -04:00
|
|
|
|
2020-05-20 20:29:21 -04:00
|
|
|
if (c < 0x80) {
|
|
|
|
if (c == L'\0' || c == L'\n')
|
|
|
|
break;
|
|
|
|
if (c == L'"')
|
|
|
|
in_quote = !in_quote;
|
|
|
|
else if (!in_quote && isspace((char)c))
|
|
|
|
safe_options_bytes = options_bytes;
|
|
|
|
|
|
|
|
options_bytes++;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2020-05-18 15:07:15 -04:00
|
|
|
/*
|
|
|
|
* Get the number of UTF-8 bytes corresponding to a
|
|
|
|
* UTF-16 character.
|
|
|
|
* The first part handles everything in the BMP.
|
|
|
|
*/
|
2020-05-20 20:29:21 -04:00
|
|
|
options_bytes += 2 + (c >= 0x800);
|
2020-05-18 15:07:15 -04:00
|
|
|
/*
|
|
|
|
* Add one more byte for valid surrogate pairs. Invalid
|
|
|
|
* surrogates will be replaced with 0xfffd and take up
|
|
|
|
* only 3 bytes.
|
|
|
|
*/
|
|
|
|
if ((c & 0xfc00) == 0xd800) {
|
|
|
|
/*
|
|
|
|
* If the very last word is a high surrogate,
|
|
|
|
* we must ignore it since we can't access the
|
|
|
|
* low surrogate.
|
|
|
|
*/
|
2020-05-18 15:07:16 -04:00
|
|
|
if (!options_chars) {
|
2020-05-18 15:07:15 -04:00
|
|
|
options_bytes -= 3;
|
|
|
|
} else if ((*s2 & 0xfc00) == 0xdc00) {
|
|
|
|
options_bytes++;
|
2020-05-18 15:07:16 -04:00
|
|
|
options_chars--;
|
2020-05-18 15:07:15 -04:00
|
|
|
s2++;
|
|
|
|
}
|
|
|
|
}
|
2013-09-22 15:45:33 -07:00
|
|
|
}
|
2020-05-20 20:29:21 -04:00
|
|
|
if (options_bytes >= COMMAND_LINE_SIZE) {
|
|
|
|
options_bytes = safe_options_bytes;
|
|
|
|
efi_err("Command line is too long: truncated to %d bytes\n",
|
|
|
|
options_bytes);
|
|
|
|
}
|
2013-09-22 15:45:33 -07:00
|
|
|
}
|
|
|
|
|
2013-09-20 09:55:39 -05:00
|
|
|
options_bytes++; /* NUL termination */
|
2014-04-04 13:25:46 +01:00
|
|
|
|
2020-05-19 10:43:01 +02:00
|
|
|
status = efi_bs_call(allocate_pool, EFI_LOADER_DATA, options_bytes,
|
|
|
|
(void **)&cmdline_addr);
|
2013-09-22 15:45:33 -07:00
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
return NULL;
|
|
|
|
|
2020-05-18 15:07:16 -04:00
|
|
|
snprintf((char *)cmdline_addr, options_bytes, "%.*ls",
|
|
|
|
options_bytes - 1, options);
|
2013-09-22 15:45:33 -07:00
|
|
|
|
|
|
|
return (char *)cmdline_addr;
|
|
|
|
}
|
2016-08-29 14:38:52 -06:00
|
|
|
|
2020-06-16 01:42:31 +02:00
|
|
|
/**
|
|
|
|
* efi_exit_boot_services() - Exit boot services
|
|
|
|
* @handle: handle of the exiting image
|
|
|
|
* @priv: argument to be passed to @priv_func
|
|
|
|
* @priv_func: function to process the memory map before exiting boot services
|
|
|
|
*
|
2016-08-29 14:38:52 -06:00
|
|
|
* Handle calling ExitBootServices according to the requirements set out by the
|
|
|
|
* spec. Obtains the current memory map, and returns that info after calling
|
|
|
|
* ExitBootServices. The client must specify a function to perform any
|
|
|
|
* processing of the memory map data prior to ExitBootServices. A client
|
|
|
|
* specific structure may be passed to the function via priv. The client
|
|
|
|
* function may be called multiple times.
|
2020-06-16 01:42:31 +02:00
|
|
|
*
|
|
|
|
* Return: status code
|
2016-08-29 14:38:52 -06:00
|
|
|
*/
|
2022-06-03 15:29:22 +02:00
|
|
|
efi_status_t efi_exit_boot_services(void *handle, void *priv,
|
2016-08-29 14:38:52 -06:00
|
|
|
efi_exit_boot_map_processing priv_func)
|
|
|
|
{
|
2022-06-03 15:29:22 +02:00
|
|
|
struct efi_boot_memmap *map;
|
2016-08-29 14:38:52 -06:00
|
|
|
efi_status_t status;
|
|
|
|
|
efi/libstub: Disable PCI DMA before grabbing the EFI memory map
Currently, the EFI stub will disable PCI DMA as the very last thing it
does before calling ExitBootServices(), to avoid interfering with the
firmware's normal operation as much as possible.
However, the stub will invoke DisconnectController() on all endpoints
downstream of the PCI bridges it disables, and this may affect the
layout of the EFI memory map, making it substantially more likely that
ExitBootServices() will fail the first time around, and that the EFI
memory map needs to be reloaded.
This, in turn, increases the likelihood that the slack space we
allocated is insufficient (and we can no longer allocate memory via boot
services after having called ExitBootServices() once), causing the
second call to GetMemoryMap (and therefore the boot) to fail. This makes
the PCI DMA disable feature a bit more fragile than it already is, so
let's make it more robust, by allocating the space for the EFI memory
map after disabling PCI DMA.
Fixes: 4444f8541dad16fe ("efi: Allow disabling PCI busmastering on bridges during boot")
Reported-by: Glenn Washburn <development@efficientek.com>
Acked-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2023-06-27 09:33:09 +02:00
|
|
|
if (efi_disable_pci_dma)
|
|
|
|
efi_pci_disable_bridge_busmaster();
|
|
|
|
|
2022-09-15 23:20:06 +02:00
|
|
|
status = efi_get_memory_map(&map, true);
|
2016-08-29 14:38:52 -06:00
|
|
|
if (status != EFI_SUCCESS)
|
2022-09-18 20:02:44 +02:00
|
|
|
return status;
|
2016-08-29 14:38:52 -06:00
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
status = priv_func(map, priv);
|
2022-09-18 20:02:44 +02:00
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
efi_bs_call(free_pool, map);
|
|
|
|
return status;
|
|
|
|
}
|
2016-08-29 14:38:52 -06:00
|
|
|
|
2022-06-03 15:29:22 +02:00
|
|
|
status = efi_bs_call(exit_boot_services, handle, map->map_key);
|
2016-08-29 14:38:52 -06:00
|
|
|
|
|
|
|
if (status == EFI_INVALID_PARAMETER) {
|
|
|
|
/*
|
|
|
|
* The memory map changed between efi_get_memory_map() and
|
|
|
|
* exit_boot_services(). Per the UEFI Spec v2.6, Section 6.4:
|
|
|
|
* EFI_BOOT_SERVICES.ExitBootServices we need to get the
|
|
|
|
* updated map, and try again. The spec implies one retry
|
|
|
|
* should be sufficent, which is confirmed against the EDK2
|
|
|
|
* implementation. Per the spec, we can only invoke
|
|
|
|
* get_memory_map() and exit_boot_services() - we cannot alloc
|
|
|
|
* so efi_get_memory_map() cannot be used, and we must reuse
|
|
|
|
* the buffer. For all practical purposes, the headroom in the
|
|
|
|
* buffer should account for any changes in the map so the call
|
|
|
|
* to get_memory_map() is expected to succeed here.
|
|
|
|
*/
|
2022-06-03 15:29:22 +02:00
|
|
|
map->map_size = map->buff_size;
|
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(get_memory_map,
|
2022-06-03 15:29:22 +02:00
|
|
|
&map->map_size,
|
|
|
|
&map->map,
|
|
|
|
&map->map_key,
|
|
|
|
&map->desc_size,
|
|
|
|
&map->desc_ver);
|
2016-08-29 14:38:52 -06:00
|
|
|
|
|
|
|
/* exit_boot_services() was called, thus cannot free */
|
|
|
|
if (status != EFI_SUCCESS)
|
2022-09-18 20:02:44 +02:00
|
|
|
return status;
|
2016-08-29 14:38:52 -06:00
|
|
|
|
2019-12-24 16:10:19 +01:00
|
|
|
status = priv_func(map, priv);
|
2016-08-29 14:38:52 -06:00
|
|
|
/* exit_boot_services() was called, thus cannot free */
|
|
|
|
if (status != EFI_SUCCESS)
|
2022-09-18 20:02:44 +02:00
|
|
|
return status;
|
2016-08-29 14:38:52 -06:00
|
|
|
|
2022-06-03 15:29:22 +02:00
|
|
|
status = efi_bs_call(exit_boot_services, handle, map->map_key);
|
2016-08-29 14:38:52 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
2019-06-07 13:51:46 -07:00
|
|
|
|
2020-06-16 01:42:31 +02:00
|
|
|
/**
|
|
|
|
* get_efi_config_table() - retrieve UEFI configuration table
|
|
|
|
* @guid: GUID of the configuration table to be retrieved
|
|
|
|
* Return: pointer to the configuration table or NULL
|
|
|
|
*/
|
2019-12-24 16:10:19 +01:00
|
|
|
void *get_efi_config_table(efi_guid_t guid)
|
2019-06-07 13:51:46 -07:00
|
|
|
{
|
2020-04-16 18:38:06 +02:00
|
|
|
unsigned long tables = efi_table_attr(efi_system_table, tables);
|
|
|
|
int nr_tables = efi_table_attr(efi_system_table, nr_tables);
|
2019-12-24 16:10:09 +01:00
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < nr_tables; i++) {
|
|
|
|
efi_config_table_t *t = (void *)tables;
|
|
|
|
|
|
|
|
if (efi_guidcmp(t->guid, guid) == 0)
|
2019-12-24 16:10:22 +01:00
|
|
|
return efi_table_attr(t, table);
|
2019-12-24 16:10:09 +01:00
|
|
|
|
|
|
|
tables += efi_is_native() ? sizeof(efi_config_table_t)
|
|
|
|
: sizeof(efi_config_table_32_t);
|
|
|
|
}
|
|
|
|
return NULL;
|
2019-06-07 13:51:46 -07:00
|
|
|
}
|
2019-12-24 16:10:16 +01:00
|
|
|
|
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-03 23:45:14 +00:00
|
|
|
/*
|
|
|
|
* The LINUX_EFI_INITRD_MEDIA_GUID vendor media device path below provides a way
|
|
|
|
* for the firmware or bootloader to expose the initrd data directly to the stub
|
|
|
|
* via the trivial LoadFile2 protocol, which is defined in the UEFI spec, and is
|
|
|
|
* very easy to implement. It is a simple Linux initrd specific conduit between
|
|
|
|
* kernel and firmware, allowing us to put the EFI stub (being part of the
|
|
|
|
* kernel) in charge of where and when to load the initrd, while leaving it up
|
|
|
|
* to the firmware to decide whether it needs to expose its filesystem hierarchy
|
|
|
|
* via EFI protocols.
|
|
|
|
*/
|
|
|
|
static const struct {
|
|
|
|
struct efi_vendor_dev_path vendor;
|
|
|
|
struct efi_generic_dev_path end;
|
|
|
|
} __packed initrd_dev_path = {
|
|
|
|
{
|
|
|
|
{
|
|
|
|
EFI_DEV_MEDIA,
|
|
|
|
EFI_DEV_MEDIA_VENDOR,
|
|
|
|
sizeof(struct efi_vendor_dev_path),
|
|
|
|
},
|
|
|
|
LINUX_EFI_INITRD_MEDIA_GUID
|
|
|
|
}, {
|
|
|
|
EFI_DEV_END_PATH,
|
|
|
|
EFI_DEV_END_ENTIRE,
|
|
|
|
sizeof(struct efi_generic_dev_path)
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
/**
|
2020-06-16 01:42:31 +02:00
|
|
|
* efi_load_initrd_dev_path() - load the initrd from the Linux initrd device path
|
2022-11-08 10:53:10 +08:00
|
|
|
* @initrd: pointer of struct to store the address where the initrd was loaded
|
|
|
|
* and the size of the loaded initrd
|
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-03 23:45:14 +00:00
|
|
|
* @max: upper limit for the initrd memory allocation
|
2020-06-16 01:42:31 +02:00
|
|
|
*
|
|
|
|
* Return:
|
|
|
|
* * %EFI_SUCCESS if the initrd was loaded successfully, in which
|
|
|
|
* case @load_addr and @load_size are assigned accordingly
|
|
|
|
* * %EFI_NOT_FOUND if no LoadFile2 protocol exists on the initrd device path
|
|
|
|
* * %EFI_OUT_OF_RESOURCES if memory allocation failed
|
|
|
|
* * %EFI_LOAD_ERROR in all other cases
|
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-03 23:45:14 +00:00
|
|
|
*/
|
2020-04-30 14:28:41 -04:00
|
|
|
static
|
2022-09-16 14:03:06 +02:00
|
|
|
efi_status_t efi_load_initrd_dev_path(struct linux_efi_initrd *initrd,
|
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-03 23:45:14 +00:00
|
|
|
unsigned long max)
|
|
|
|
{
|
|
|
|
efi_guid_t lf2_proto_guid = EFI_LOAD_FILE2_PROTOCOL_GUID;
|
|
|
|
efi_device_path_protocol_t *dp;
|
|
|
|
efi_load_file2_protocol_t *lf2;
|
|
|
|
efi_handle_t handle;
|
|
|
|
efi_status_t status;
|
|
|
|
|
|
|
|
dp = (efi_device_path_protocol_t *)&initrd_dev_path;
|
|
|
|
status = efi_bs_call(locate_device_path, &lf2_proto_guid, &dp, &handle);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
status = efi_bs_call(handle_protocol, handle, &lf2_proto_guid,
|
|
|
|
(void **)&lf2);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
return status;
|
|
|
|
|
2022-09-16 14:03:06 +02:00
|
|
|
initrd->size = 0;
|
|
|
|
status = efi_call_proto(lf2, load_file, dp, false, &initrd->size, NULL);
|
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-03 23:45:14 +00:00
|
|
|
if (status != EFI_BUFFER_TOO_SMALL)
|
|
|
|
return EFI_LOAD_ERROR;
|
|
|
|
|
2022-09-16 14:03:06 +02:00
|
|
|
status = efi_allocate_pages(initrd->size, &initrd->base, max);
|
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-03 23:45:14 +00:00
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
return status;
|
|
|
|
|
2022-09-16 14:03:06 +02:00
|
|
|
status = efi_call_proto(lf2, load_file, dp, false, &initrd->size,
|
|
|
|
(void *)initrd->base);
|
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-03 23:45:14 +00:00
|
|
|
if (status != EFI_SUCCESS) {
|
2022-09-16 14:03:06 +02:00
|
|
|
efi_free(initrd->size, initrd->base);
|
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-03 23:45:14 +00:00
|
|
|
return EFI_LOAD_ERROR;
|
|
|
|
}
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
}
|
2020-04-30 14:28:41 -04:00
|
|
|
|
|
|
|
static
|
|
|
|
efi_status_t efi_load_initrd_cmdline(efi_loaded_image_t *image,
|
2022-09-16 14:03:06 +02:00
|
|
|
struct linux_efi_initrd *initrd,
|
2020-04-30 14:28:41 -04:00
|
|
|
unsigned long soft_limit,
|
|
|
|
unsigned long hard_limit)
|
|
|
|
{
|
2022-11-29 18:23:08 +01:00
|
|
|
if (image == NULL)
|
2022-09-16 14:03:06 +02:00
|
|
|
return EFI_UNSUPPORTED;
|
2020-04-30 14:28:41 -04:00
|
|
|
|
|
|
|
return handle_cmdline_files(image, L"initrd=", sizeof(L"initrd=") - 2,
|
|
|
|
soft_limit, hard_limit,
|
2022-09-16 14:03:06 +02:00
|
|
|
&initrd->base, &initrd->size);
|
2020-04-30 14:28:41 -04:00
|
|
|
}
|
|
|
|
|
2020-06-16 01:42:31 +02:00
|
|
|
/**
|
|
|
|
* efi_load_initrd() - Load initial RAM disk
|
|
|
|
* @image: EFI loaded image protocol
|
2021-07-02 12:10:44 -07:00
|
|
|
* @soft_limit: preferred address for loading the initrd
|
|
|
|
* @hard_limit: upper limit address for loading the initrd
|
2025-05-07 00:31:11 +08:00
|
|
|
* @out: pointer to store the address of the initrd table
|
2020-06-16 01:42:31 +02:00
|
|
|
*
|
|
|
|
* Return: status code
|
|
|
|
*/
|
2020-04-30 14:28:41 -04:00
|
|
|
efi_status_t efi_load_initrd(efi_loaded_image_t *image,
|
|
|
|
unsigned long soft_limit,
|
2022-09-16 14:03:06 +02:00
|
|
|
unsigned long hard_limit,
|
|
|
|
const struct linux_efi_initrd **out)
|
2020-04-30 14:28:41 -04:00
|
|
|
{
|
2022-09-16 14:03:06 +02:00
|
|
|
efi_guid_t tbl_guid = LINUX_EFI_INITRD_MEDIA_GUID;
|
|
|
|
efi_status_t status = EFI_SUCCESS;
|
|
|
|
struct linux_efi_initrd initrd, *tbl;
|
2020-04-30 14:28:41 -04:00
|
|
|
|
2022-09-16 14:03:06 +02:00
|
|
|
if (!IS_ENABLED(CONFIG_BLK_DEV_INITRD) || efi_noinitrd)
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
|
|
|
|
status = efi_load_initrd_dev_path(&initrd, hard_limit);
|
|
|
|
if (status == EFI_SUCCESS) {
|
|
|
|
efi_info("Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path\n");
|
|
|
|
} else if (status == EFI_NOT_FOUND) {
|
|
|
|
status = efi_load_initrd_cmdline(image, &initrd, soft_limit,
|
|
|
|
hard_limit);
|
|
|
|
/* command line loader disabled or no initrd= passed? */
|
|
|
|
if (status == EFI_UNSUPPORTED || status == EFI_NOT_READY)
|
|
|
|
return EFI_SUCCESS;
|
|
|
|
if (status == EFI_SUCCESS)
|
|
|
|
efi_info("Loaded initrd from command line option\n");
|
2021-11-19 13:47:44 +02:00
|
|
|
}
|
2022-09-16 14:03:06 +02:00
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
goto failed;
|
|
|
|
|
2024-09-30 22:20:28 -05:00
|
|
|
if (initrd.size > 0 &&
|
|
|
|
efi_measure_tagged_event(initrd.base, initrd.size,
|
|
|
|
EFISTUB_EVT_INITRD) == EFI_SUCCESS)
|
|
|
|
efi_info("Measured initrd data into PCR 9\n");
|
|
|
|
|
2022-09-16 14:03:06 +02:00
|
|
|
status = efi_bs_call(allocate_pool, EFI_LOADER_DATA, sizeof(initrd),
|
|
|
|
(void **)&tbl);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
goto free_initrd;
|
|
|
|
|
|
|
|
*tbl = initrd;
|
|
|
|
status = efi_bs_call(install_configuration_table, &tbl_guid, tbl);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
goto free_tbl;
|
|
|
|
|
|
|
|
if (out)
|
|
|
|
*out = tbl;
|
|
|
|
return EFI_SUCCESS;
|
2020-04-30 14:28:41 -04:00
|
|
|
|
2022-09-16 14:03:06 +02:00
|
|
|
free_tbl:
|
|
|
|
efi_bs_call(free_pool, tbl);
|
|
|
|
free_initrd:
|
|
|
|
efi_free(initrd.size, initrd.base);
|
|
|
|
failed:
|
|
|
|
efi_err("Failed to load initrd: 0x%lx\n", status);
|
2020-04-30 14:28:41 -04:00
|
|
|
return status;
|
|
|
|
}
|
2020-05-18 15:07:11 -04:00
|
|
|
|
2020-06-16 01:42:31 +02:00
|
|
|
/**
|
|
|
|
* efi_wait_for_key() - Wait for key stroke
|
|
|
|
* @usec: number of microseconds to wait for key stroke
|
|
|
|
* @key: key entered
|
|
|
|
*
|
|
|
|
* Wait for up to @usec microseconds for a key stroke.
|
|
|
|
*
|
|
|
|
* Return: status code, EFI_SUCCESS if key received
|
|
|
|
*/
|
2020-05-18 15:07:11 -04:00
|
|
|
efi_status_t efi_wait_for_key(unsigned long usec, efi_input_key_t *key)
|
|
|
|
{
|
|
|
|
efi_event_t events[2], timer;
|
|
|
|
unsigned long index;
|
|
|
|
efi_simple_text_input_protocol_t *con_in;
|
|
|
|
efi_status_t status;
|
|
|
|
|
|
|
|
con_in = efi_table_attr(efi_system_table, con_in);
|
|
|
|
if (!con_in)
|
|
|
|
return EFI_UNSUPPORTED;
|
|
|
|
efi_set_event_at(events, 0, efi_table_attr(con_in, wait_for_key));
|
|
|
|
|
|
|
|
status = efi_bs_call(create_event, EFI_EVT_TIMER, 0, NULL, NULL, &timer);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
return status;
|
|
|
|
|
|
|
|
status = efi_bs_call(set_timer, timer, EfiTimerRelative,
|
|
|
|
EFI_100NSEC_PER_USEC * usec);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
return status;
|
|
|
|
efi_set_event_at(events, 1, timer);
|
|
|
|
|
|
|
|
status = efi_bs_call(wait_for_event, 2, events, &index);
|
|
|
|
if (status == EFI_SUCCESS) {
|
|
|
|
if (index == 0)
|
|
|
|
status = efi_call_proto(con_in, read_keystroke, key);
|
|
|
|
else
|
|
|
|
status = EFI_TIMEOUT;
|
|
|
|
}
|
|
|
|
|
|
|
|
efi_bs_call(close_event, timer);
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
2023-01-30 13:11:53 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* efi_remap_image - Remap a loaded image with the appropriate permissions
|
|
|
|
* for code and data
|
|
|
|
*
|
|
|
|
* @image_base: the base of the image in memory
|
|
|
|
* @alloc_size: the size of the area in memory occupied by the image
|
|
|
|
* @code_size: the size of the leading part of the image containing code
|
|
|
|
* and read-only data
|
|
|
|
*
|
|
|
|
* efi_remap_image() uses the EFI memory attribute protocol to remap the code
|
|
|
|
* region of the loaded image read-only/executable, and the remainder
|
|
|
|
* read-write/non-executable. The code region is assumed to start at the base
|
|
|
|
* of the image, and will therefore cover the PE/COFF header as well.
|
|
|
|
*/
|
|
|
|
void efi_remap_image(unsigned long image_base, unsigned alloc_size,
|
|
|
|
unsigned long code_size)
|
|
|
|
{
|
|
|
|
efi_guid_t guid = EFI_MEMORY_ATTRIBUTE_PROTOCOL_GUID;
|
|
|
|
efi_memory_attribute_protocol_t *memattr;
|
|
|
|
efi_status_t status;
|
|
|
|
u64 attr;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the firmware implements the EFI_MEMORY_ATTRIBUTE_PROTOCOL, let's
|
|
|
|
* invoke it to remap the text/rodata region of the decompressed image
|
|
|
|
* as read-only and the data/bss region as non-executable.
|
|
|
|
*/
|
|
|
|
status = efi_bs_call(locate_protocol, &guid, NULL, (void **)&memattr);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Get the current attributes for the entire region
|
|
|
|
status = memattr->get_memory_attributes(memattr, image_base,
|
|
|
|
alloc_size, &attr);
|
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
efi_warn("Failed to retrieve memory attributes for image region: 0x%lx\n",
|
|
|
|
status);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Mark the code region as read-only
|
|
|
|
status = memattr->set_memory_attributes(memattr, image_base, code_size,
|
|
|
|
EFI_MEMORY_RO);
|
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
efi_warn("Failed to remap code region read-only\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If the entire region was already mapped as non-exec, clear the
|
|
|
|
// attribute from the code region. Otherwise, set it on the data
|
|
|
|
// region.
|
|
|
|
if (attr & EFI_MEMORY_XP) {
|
|
|
|
status = memattr->clear_memory_attributes(memattr, image_base,
|
|
|
|
code_size,
|
|
|
|
EFI_MEMORY_XP);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
efi_warn("Failed to remap code region executable\n");
|
|
|
|
} else {
|
|
|
|
status = memattr->set_memory_attributes(memattr,
|
|
|
|
image_base + code_size,
|
|
|
|
alloc_size - code_size,
|
|
|
|
EFI_MEMORY_XP);
|
|
|
|
if (status != EFI_SUCCESS)
|
|
|
|
efi_warn("Failed to remap data region non-executable\n");
|
|
|
|
}
|
|
|
|
}
|