lwn.git/drivers/firmware/efi/libstub/arm-stub.c, branch docs-next

efi/libstub: Move arm-stub to a common file

2020-04-23T12:16:28+00:00

Most of the arm-stub code is written in an architecture independent manner. As a result, RISC-V can reuse most of the arm-stub code. Rename the arm-stub.c to efi-stub.c so that ARM, ARM64 and RISC-V can use it. This patch doesn't introduce any functional changes. Signed-off-by: Atish Patra Reviewed-by: Palmer Dabbelt Link: https://lore.kernel.org/r/20200415195422.19866-2-atish.patra@wdc.com Signed-off-by: Ard Biesheuvel

efi/libstub/arm: Fix spurious message that an initrd was loaded

2020-03-29T10:08:18+00:00

Commit: ec93fc371f014a6f ("efi/libstub: Add support for loading the initrd from a device path") added a diagnostic print to the ARM version of the EFI stub that reports whether an initrd has been loaded that was passed via the command line using initrd=. However, it failed to take into account that, for historical reasons, the file loading routines return EFI_SUCCESS when no file was found, and the only way to decide whether a file was loaded is to inspect the 'size' argument that is passed by reference. So let's inspect this returned size, to prevent the print from being emitted even if no initrd was loaded at all. Signed-off-by: Ard Biesheuvel Signed-off-by: Ingo Molnar Cc: Thomas Gleixner Cc: linux-arm-kernel@lists.infradead.org Cc: linux-efi@vger.kernel.org

efi/libstub: Take noinitrd cmdline argument into account for devpath initrd

2020-02-23T20:59:42+00:00

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 Signed-off-by: Ard Biesheuvel

efi/libstub: Add support for loading the initrd from a device path

2020-02-23T20:59:42+00:00

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 Tested-by: Ilias Apalodimas Acked-by: Ilias Apalodimas Signed-off-by: Ard Biesheuvel

efi/libstub: Take soft and hard memory limits into account for initrd loading

2020-02-23T20:57:15+00:00

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

efi/libstub: Rewrite file I/O routine

2020-02-23T20:57:15+00:00

The file I/O routine that is used to load initrd or dtb files from the EFI system partition suffers from a few issues: - it converts the u8[] command line back to a UTF-16 string, which is pointless since we only handle initrd or dtb arguments provided via the loaded image protocol anyway, which is where we got the UTF-16[] command line from in the first place when booting via the PE entry point, - in the far majority of cases, only a single initrd= option is present, but it optimizes for multiple options, by going over the command line twice, allocating heap buffers for dynamically sized arrays, etc. - the coding style is hard to follow, with few comments, and all logic including string parsing etc all combined in a single routine. Let's fix this by rewriting most of it, based on the idea that in the case of multiple initrds, we can just allocate a new, bigger buffer and copy over the data before freeing the old one. Signed-off-by: Ard Biesheuvel

efi/libstub: Move get_dram_base() into arm-stub.c

2020-02-23T20:57:15+00:00

get_dram_base() is only called from arm-stub.c so move it into the same source file as its caller. Signed-off-by: Ard Biesheuvel

efi/libstub/x86: Permit cmdline data to be allocated above 4 GB

2020-02-23T20:57:15+00:00

We now support cmdline data that is located in memory that is not 32-bit addressable, so relax the allocation limit on systems where this feature is enabled. Signed-off-by: Ard Biesheuvel

efi/libstub/arm64: Use 1:1 mapping of RT services if property table exists

2020-02-22T22:37:37+00:00

The UEFI spec defines (and deprecates) a misguided and shortlived memory protection feature that is based on splitting memory regions covering PE/COFF executables into separate code and data regions, without annotating them as belonging to the same executable image. When the OS assigns the virtual addresses of these regions, it may move them around arbitrarily, without taking into account that the PE/COFF code sections may contain relative references into the data sections, which means the relative placement of these segments has to be preserved or the executable image will be corrupted. The original workaround on arm64 was to ensure that adjacent regions of the same type were mapped adjacently in the virtual mapping, but this requires sorting of the memory map, which we would prefer to avoid. Considering that the native physical mapping of the PE/COFF images does not suffer from this issue, let's preserve it at runtime, and install it as the virtual mapping as well. Signed-off-by: Ard Biesheuvel

efi/libstub/arm: Make efi_entry() an ordinary PE/COFF entrypoint

2020-02-22T22:37:37+00:00

Expose efi_entry() as the PE/COFF entrypoint directly, instead of jumping into a wrapper that fiddles with stack buffers and other stuff that the compiler is much better at. The only reason this code exists is to obtain a pointer to the base of the image, but we can get the same value from the loaded_image protocol, which we already need for other reasons anyway. Update the return type as well, to make it consistent with what is required for a PE/COFF executable entrypoint. Signed-off-by: Ard Biesheuvel