- 23 Feb, 2020 40 commits
-
-
Ard Biesheuvel authored
Currently, we either return with an error [from efi_pe_entry()] or enter a deadloop [in efi_main()] if any fatal errors occur during execution of the EFI stub. Let's switch to calling the Exit() EFI boot service instead in both cases, so that we a) can get rid of the deadloop, and simply return to the boot manager if any errors occur during execution of the stub, including during the call to ExitBootServices(), b) can also return cleanly from efi_pe_entry() or efi_main() in mixed mode, once we introduce support for LoadImage/StartImage based mixed mode in the next patch. Note that on systems running downstream GRUBs [which do not use LoadImage or StartImage to boot the kernel, and instead, pass their own image handle as the loaded image handle], calling Exit() will exit from GRUB rather than from the kernel, but this is a tolerable side effect. Signed-off-by:Ard Biesheuvel <ardb@kernel.org>
-
Ard Biesheuvel authored
Add the definitions and use the special wrapper so that the loaded_image UEFI protocol can be safely used from mixed mode. Signed-off-by: -
Ard Biesheuvel authored
In commit c7fb93ec ("x86/efi: Include a .bss section within the PE/COFF headers") we added a separate .bss section to the PE/COFF header of the compressed kernel describing the static memory footprint of the decompressor, to ensure that it has enough headroom to decompress itself. We can achieve the exact same result by increasing the virtual size of the .text section, without changing the raw size, which, as per the PE/COFF specification, requires the loader to zero initialize the delta. Doing so frees up a slot in the section table, which we will use later to describe the mixed mode entrypoint. Signed-off-by:
-
Ard Biesheuvel authored
In the bootparams struct, init_size defines the static footprint of the bzImage, counted from the start of the kernel image, i.e., startup_32(). The PE/COFF metadata declares the same size for the entire image, but this time, the image includes the setup block as well, and so the space reserved by UEFI is a bit too small. This usually doesn't matter, since we normally relocate the kernel into a memory allocation of the correct size. But in the unlikely case that the image happens to be loaded at exactly the preferred offset, we skip this relocation, and execute the image in place, stepping on memory beyond the provided allocation, which may be in use for other purposes. Let's fix this by adding the size of the setup block to the image size as declared in the PE/COFF header. Signed-off-by: -
Ard Biesheuvel authored
The systab member in struct efi has outlived its usefulness, now that we have better ways to access the only piece of information we are interested in after init, which is the EFI runtime services table address. So instead of instantiating a doctored copy at early boot with lots of mangled values, and switching the pointer when switching into virtual mode, let's grab the values we need directly, and get rid of the systab pointer entirely. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
Instead of populating efi.systab very early during efi_init() with a mapping that is released again before the function exits, use a local variable here. Now that we use efi.runtime to access the runtime services table, this removes the only reference efi.systab, so there is no need to populate it anymore, or discover its virtually remapped address. So drop the references entirely. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
Instead of going through the EFI system table each time, just copy the runtime services table pointer into struct efi directly. This is the last use of the system table pointer in struct efi, allowing us to drop it in a future patch, along with a fair amount of quirky handling of the translated address. Note that usually, the runtime services pointer changes value during the call to SetVirtualAddressMap(), so grab the updated value as soon as that call returns. (Mixed mode uses a 1:1 mapping, and kexec boot enters with the updated address in the system table, so in those cases, we don't need to do anything here) Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
efi.runtime_version is always set to the same value on both existing code paths, so just set it earlier from a shared one. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
There is some code that exposes physical addresses of certain parts of the EFI firmware implementation via sysfs nodes. These nodes are only used on x86, and are of dubious value to begin with, so let's move their handling into the x86 arch code. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
Since commit 33b85447 ("efi/x86: Drop two near identical versions of efi_runtime_init()"), we no longer map the EFI runtime services table before calling SetVirtualAddressMap(), which means we don't need the 1:1 mapped physical address of this table, and so there is no point in passing the address via EFI setup data on kexec boot. Note that the kexec tools will still look for this address in sysfs, so we still need to provide it. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by:
-
Ard Biesheuvel authored
config_parse_tables() is a jumble of pointer arithmetic, due to the fact that on x86, we may be dealing with firmware whose native word size differs from the kernel's. This is not a concern on other architectures, and doesn't quite justify the state of the code, so let's clean it up by adding a non-x86 code path, constifying statically allocated tables and replacing preprocessor conditionals with IS_ENABLED() checks. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
The efi_config_init() routine is no longer shared with ia64 so let's move it into the x86 arch code before making further x86 specific changes to it. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
IA64 calls efi_config_parse_tables() via efi_config_init(), which does an explicit memremap() of the tables, which is unnecessary on IA64. So let's call efi_config_parse_tables() directly, passing the __va() of the config table array. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
The IA64 code never refers to the EFI system table except from inside the scope of efi_init(). So let's use a local variable instead of efi.systab, which will be going away soon. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
Instead of iterating over the EFI config table array manually, declare it as an arch table so it gets picked up by the existing config table handling code. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
We have three different versions of the code that checks the EFI system table revision and copies the firmware vendor string, and they are mostly equivalent, with the exception of the use of early_memremap_ro vs. __va() and the lowest major revision to warn about. Let's move this into common code and factor out the commonalities. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
There is no need for struct efi to carry the address of the memreserve table and share it with the world. So move it out and make it __initdata as well. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
The memory attributes table is only used at init time by the core EFI code, so there is no need to carry its address in struct efi that is shared with the world. So move it out, and make it __ro_after_init as well, considering that the value is set during early boot. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
Move the rng_seed table address from struct efi into a static global variable in efi.c, which is the only place we ever refer to it anyway. This reduces the footprint of struct efi, which is a r/w data structure that is shared with the world. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
The UGA table is x86 specific (its handling was introduced when the EFI support code was modified to accommodate IA32), so there is no need to handle it in generic code. The EFI properties table is not strictly x86 specific, but it was deprecated almost immediately after having been introduced, due to implementation difficulties. Only x86 takes it into account today, and this is not going to change, so make this table x86 only as well. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
The HCDP and MPS tables are Itanium specific EFI config tables, so move their handling to ia64 arch code. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
Some plumbing exists to handle a UEFI configuration table of type BOOT_INFO but since we never match it to a GUID anywhere, we never actually register such a table, or access it, for that matter. So simply drop all mentions of it. Tested-by: Tony Luck <tony.luck@intel.com> # arch/ia64 Signed-off-by: -
Ard Biesheuvel authored
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 authored
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:
-
Ard Biesheuvel authored
In preparation of adding support for loading the initrd via a special device path, add the struct definition of a vendor GUIDed device path node to efi.h. Since we will be producing these data structures rather than just consumsing the ones instantiated by the firmware, refactor the various device path node definitions so we can take the size of each node using sizeof() rather than having to resort to opaque arithmetic in the static initializers. While at it, drop the #if IS_ENABLED() check for the declaration of efi_get_device_by_path(), which is unnecessary, and constify its first argument as well. Signed-off-by: -
Ard Biesheuvel authored
When possible, IS_ENABLED() conditionals are preferred over #ifdefs, given that the latter hide the code from the compiler entirely, which reduces build test coverage when the option is not enabled. So replace an instance in the x86 efi startup code. Signed-off-by: -
Ard Biesheuvel authored
Reindent the efi_memory_map_data initializer so that all the = signs are aligned vertically, making the resulting code much easier to read. Suggested-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Heinrich Schuchardt authored
In efi_capsule_write() the value 0 assigned to ret is never used. Identified with cppcheck. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Link: https://lore.kernel.org/r/20200223205435.114915-1-xypron.glpk@gmx.deSigned-off-by:
-
Heinrich Schuchardt authored
Remove an unused variable in __init efi_esrt_init(). Simplify a logical constraint. Signed-off-by:
-
Heinrich Schuchardt authored
The memory for files is allocated not reallocated. Signed-off-by:
-
Heinrich Schuchardt authored
Provide descriptions for the functions invoking the EFI_RNG_PROTOCOL. Signed-off-by:
Dominik Brodowski <linux@dominikbrodowski.net> Link: https://lore.kernel.org/r/20200221114716.4372-1-xypron.glpk@gmx.deSigned-off-by:
-
Heinrich Schuchardt authored
Update the description of of efi_relocate_kernel() to match Sphinx style. Update parameter references in the description of other memory functions to use @param style. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20200220065317.9096-1-xypron.glpk@gmx.deSigned-off-by:
-
Heinrich Schuchardt authored
Provide descriptions of: * efi_get_memory_map() * efi_low_alloc_above() * efi_free() Signed-off-by:
-
Heinrich Schuchardt authored
Do not check the value of status twice. Signed-off-by:
-
Heinrich Schuchardt authored
Provide a Sphinx style function description for efi_allocate_pages(). Signed-off-by:
-
Ard Biesheuvel authored
Add the protocol definitions, GUIDs and mixed mode glue so that the EFI loadfile protocol can be used from the stub. This will be used in a future patch to load the initrd. Signed-off-by: -
Ard Biesheuvel authored
We will be adding support for loading the initrd from a GUIDed device path in a subsequent patch, so update the prototype of the LocateDevicePath() boot service to make it callable from our code. Signed-off-by: -
Ard Biesheuvel authored
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 authored
On x86, the preferred load address of the initrd is still below 4 GB, even though in some cases, we can cope with an initrd that is loaded above that. To simplify the code, and to make it more straightforward to introduce other ways to load the initrd, pass the soft and hard memory limits at the same time, and let the code handling the initrd= command line option deal with this. Signed-off-by: -
Ard Biesheuvel authored
The file I/O routine that is used to load initrd or dtb files from the EFI system partition suffers from a few issues: - it converts the u8[] command line back to a UTF-16 string, which is pointless since we only handle initrd or dtb arguments provided via the loaded image protocol anyway, which is where we got the UTF-16[] command line from in the first place when booting via the PE entry point, - in the far majority of cases, only a single initrd= option is present, but it optimizes for multiple options, by going over the command line twice, allocating heap buffers for dynamically sized arrays, etc. - the coding style is hard to follow, with few comments, and all logic including string parsing etc all combined in a single routine. Let's fix this by rewriting most of it, based on the idea that in the case of multiple initrds, we can just allocate a new, bigger buffer and copy over the data before freeing the old one. Signed-off-by:
-
