kernel.git/drivers/firmware/efi/efi.c, branch linux-6.3.y

Revert "efi: random: refresh non-volatile random seed when RNG is initialized"

2023-06-28T09:13:58Z

commit 69cbeb61ff9093a9155cb19a36d633033f71093a upstream. This reverts commit e7b813b32a42a3a6281a4fd9ae7700a0257c1d50 (and the subsequent fix for it: 41a15855c1ee "efi: random: fix NULL-deref when refreshing seed"). It turns otu to cause non-deterministic boot stalls on at least a HP 6730b laptop. Reported-and-bisected-by: Sami Korkalainen Link: https://lore.kernel.org/all/GQUnKz2al3yke5mB2i1kp3SzNHjK8vi6KJEh7rnLrOQ24OrlljeCyeWveLW9pICEmB9Qc8PKdNt3w1t_g3-Uvxq1l8Wj67PpoMeWDoH8PKk=@proton.me/ Cc: Jason A. Donenfeld Cc: Bagas Sanjaya Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

Merge tag 'efi-next-for-v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi

2023-02-23T22:41:48Z

Pull EFI updates from Ard Biesheuvel: "A healthy mix of EFI contributions this time: - Performance tweaks for efifb earlycon (Andy) - Preparatory refactoring and cleanup work in the efivar layer, which is needed to accommodate the Snapdragon arm64 laptops that expose their EFI variable store via a TEE secure world API (Johan) - Enhancements to the EFI memory map handling so that Xen dom0 can safely access EFI configuration tables (Demi Marie) - Wire up the newly introduced IBT/BTI flag in the EFI memory attributes table, so that firmware that is generated with ENDBR/BTI landing pads will be mapped with enforcement enabled - Clean up how we check and print the EFI revision exposed by the firmware - Incorporate EFI memory attributes protocol definition and wire it up in the EFI zboot code (Evgeniy) This ensures that these images can execute under new and stricter rules regarding the default memory permissions for EFI page allocations (More work is in progress here) - CPER header cleanup (Dan Williams) - Use a raw spinlock to protect the EFI runtime services stack on arm64 to ensure the correct semantics under -rt (Pierre) - EFI framebuffer quirk for Lenovo Ideapad (Darrell)" * tag 'efi-next-for-v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: (24 commits) firmware/efi sysfb_efi: Add quirk for Lenovo IdeaPad Duet 3 arm64: efi: Make efi_rt_lock a raw_spinlock efi: Add mixed-mode thunk recipe for GetMemoryAttributes efi: x86: Wire up IBT annotation in memory attributes table efi: arm64: Wire up BTI annotation in memory attributes table efi: Discover BTI support in runtime services regions efi/cper, cxl: Remove cxl_err.h efi: Use standard format for printing the EFI revision efi: Drop minimum EFI version check at boot efi: zboot: Use EFI protocol to remap code/data with the right attributes efi/libstub: Add memory attribute protocol definitions efi: efivars: prevent double registration efi: verify that variable services are supported efivarfs: always register filesystem efi: efivars: add efivars printk prefix efi: Warn if trying to reserve memory under Xen efi: Actually enable the ESRT under Xen efi: Apply allowlist to EFI configuration tables when running under Xen efi: xen: Implement memory descriptor lookup based on hypercall efi: memmap: Disregard bogus entries instead of returning them ...

efi: Use standard format for printing the EFI revision

2023-02-03T17:09:00Z

The UEFI spec section 4.2.1 describes the way the human readable EFI revision should be constructed from the 32-bit revision field in the system table: The upper 16 bits of this field contain the major revision value, and the lower 16 bits contain the minor revision value. The minor revision values are binary coded decimals and are limited to the range of 00..99. When printed or displayed UEFI spec revision is referred as (Major revision).(Minor revision upper decimal).(Minor revision lower decimal) or (Major revision).(Minor revision upper decimal) in case Minor revision lower decimal is set to 0. Let's adhere to this when logging the EFI revision to the kernel log. Note that the bit about binary coded decimals is bogus, and the minor revision lower decimal is simply the minor revision modulo 10, given the symbolic definitions provided by the spec itself: #define EFI_2_40_SYSTEM_TABLE_REVISION ((2<<16) | (40)) #define EFI_2_31_SYSTEM_TABLE_REVISION ((2<<16) | (31)) #define EFI_2_30_SYSTEM_TABLE_REVISION ((2<<16) | (30)) Signed-off-by: Ard Biesheuvel

efi: Drop minimum EFI version check at boot

2023-02-03T17:01:07Z

We currently pass a minimum major version to the generic EFI helper that checks the system table magic and version, and refuse to boot if the value is lower. The motivation for this check is unknown, and even the code that uses major version 2 as the minimum (ARM, arm64 and RISC-V) should make it past this check without problems, and boot to a point where we have access to a console or some other means to inform the user that the firmware's major revision number made us unhappy. (Revision 2.0 of the UEFI specification was released in January 2006, whereas ARM, arm64 and RISC-V support where added in 2009, 2013 and 2017, respectively, so checking for major version 2 or higher is completely arbitrary) So just drop the check. Signed-off-by: Ard Biesheuvel

efi: fix potential NULL deref in efi_mem_reserve_persistent

2023-02-03T13:52:10Z

When iterating on a linked list, a result of memremap is dereferenced without checking it for NULL. This patch adds a check that falls back on allocating a new page in case memremap doesn't succeed. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 18df7577adae ("efi/memreserve: deal with memreserve entries in unmapped memory") Signed-off-by: Anton Gusev [ardb: return -ENOMEM instead of breaking out of the loop] Signed-off-by: Ard Biesheuvel

efi: verify that variable services are supported

2023-01-26T20:32:01Z

Current Qualcomm UEFI firmware does not implement the variable services but not all revisions clear the corresponding bits in the RT_PROP table services mask and instead the corresponding calls return EFI_UNSUPPORTED. This leads to efi core registering the generic efivar ops even when the variable services are not supported or when they are accessed through some other interface (e.g. Google SMI or the upcoming Qualcomm SCM implementation). Instead of playing games with init call levels to make sure that the custom implementations are registered after the generic one, make sure that get_next_variable() is actually supported before registering the generic ops. Signed-off-by: Johan Hovold Signed-off-by: Ard Biesheuvel

efi: Warn if trying to reserve memory under Xen

2023-01-23T10:33:24Z

Doing so cannot work and should never happen. Signed-off-by: Demi Marie Obenour Tested-by: Marek Marczykowski-Górecki Signed-off-by: Ard Biesheuvel

efi: Apply allowlist to EFI configuration tables when running under Xen

2023-01-23T10:33:24Z

As it turns out, Xen does not guarantee that EFI boot services data regions in memory are preserved, which means that EFI configuration tables pointing into such memory regions may be corrupted before the dom0 OS has had a chance to inspect them. This is causing problems for Qubes OS when it attempts to perform system firmware updates, which requires that the contents of the EFI System Resource Table are valid when the fwupd userspace program runs. However, other configuration tables such as the memory attributes table or the runtime properties table are equally affected, and so we need a comprehensive workaround that works for any table type. So when running under Xen, check the EFI memory descriptor covering the start of the table, and disregard the table if it does not reside in memory that is preserved by Xen. Co-developed-by: Ard Biesheuvel Signed-off-by: Ard Biesheuvel Signed-off-by: Demi Marie Obenour Tested-by: Marek Marczykowski-Górecki Signed-off-by: Ard Biesheuvel

efi: xen: Implement memory descriptor lookup based on hypercall

2023-01-22T09:14:15Z

Xen on x86 boots dom0 in EFI mode but without providing a memory map. This means that some consistency checks we would like to perform on configuration tables or other data structures in memory are not currently possible. Xen does, however, expose EFI memory descriptor info via a Xen hypercall, so let's wire that up instead. It turns out that the returned information is not identical to what Linux's efi_mem_desc_lookup would return: the address returned is the address passed to the hypercall, and the size returned is the number of bytes remaining in the configuration table. However, none of the callers of efi_mem_desc_lookup() currently care about this. In the future, Xen may gain a hypercall that returns the actual start address, which can be used instead. Co-developed-by: Ard Biesheuvel Signed-off-by: Ard Biesheuvel Signed-off-by: Demi Marie Obenour Tested-by: Marek Marczykowski-Górecki Signed-off-by: Ard Biesheuvel

efi: memmap: Disregard bogus entries instead of returning them

2023-01-22T09:14:15Z

The ESRT code currently contains two consistency checks on the memory descriptor it obtains, but one of them is both incomplete and can only trigger on invalid descriptors. So let's drop these checks, and instead disregard descriptors entirely if the start address is misaligned, or if the number of pages reaches to or beyond the end of the address space. Note that the memory map as a whole could still be inconsistent: multiple entries might cover the same area, or the address could be outside of the addressable PA space, but validating that goes beyond the scope of these helpers. Also note that since the physical address space is never 64-bits wide, a descriptor that includes the last page of memory is not valid. This is fortunate, since it means that a valid physical address will never be an error pointer and that the length of a memory descriptor in bytes will fit in a 64-bit unsigned integer. Co-developed-by: Ard Biesheuvel Signed-off-by: Ard Biesheuvel Signed-off-by: Demi Marie Obenour Tested-by: Marek Marczykowski-Górecki Signed-off-by: Ard Biesheuvel