kernel/git/stable/linux-stable.git/drivers/firmware/efi, branch linux-5.13.y

efi/libstub: arm64: Double check image alignment at entry

2021-08-18T07:07:07+00:00

commit c32ac11da3f83bb42b986702a9b92f0a14ed4182 upstream. On arm64, the stub only moves the kernel image around in memory if needed, which is typically only for KASLR, given that relocatable kernels (which is the default) can run from any 64k aligned address, which is also the minimum alignment communicated to EFI via the PE/COFF header. Unfortunately, some loaders appear to ignore this header, and load the kernel at some arbitrary offset in memory. We can deal with this, but let's check for this condition anyway, so non-compliant code can be spotted and fixed. Cc: # v5.10+ Signed-off-by: Ard Biesheuvel Tested-by: Benjamin Herrenschmidt Signed-off-by: Greg Kroah-Hartman

efi/libstub: arm64: Relax 2M alignment again for relocatable kernels

2021-08-18T07:07:03+00:00

[ Upstream commit 3a262423755b83a5f85009ace415d6e7f572dfe8 ] Commit 82046702e288 ("efi/libstub/arm64: Replace 'preferred' offset with alignment check") simplified the way the stub moves the kernel image around in memory before booting it, given that a relocatable image does not need to be copied to a 2M aligned offset if it was loaded on a 64k boundary by EFI. Commit d32de9130f6c ("efi/arm64: libstub: Deal gracefully with EFI_RNG_PROTOCOL failure") inadvertently defeated this logic by overriding the value of efi_nokaslr if EFI_RNG_PROTOCOL is not available, which was mistaken by the loader logic as an explicit request on the part of the user to disable KASLR and any associated relocation of an Image not loaded on a 2M boundary. So let's reinstate this functionality, by capturing the value of efi_nokaslr at function entry to choose the minimum alignment. Fixes: d32de9130f6c ("efi/arm64: libstub: Deal gracefully with EFI_RNG_PROTOCOL failure") Signed-off-by: Ard Biesheuvel Tested-by: Benjamin Herrenschmidt Signed-off-by: Sasha Levin

efi/libstub: arm64: Force Image reallocation if BSS was not reserved

2021-08-18T07:07:03+00:00

[ Upstream commit 5b94046efb4706b3429c9c8e7377bd8d1621d588 ] Distro versions of GRUB replace the usual LoadImage/StartImage calls used to load the kernel image with some local code that fails to honor the allocation requirements described in the PE/COFF header, as it does not account for the image's BSS section at all: it fails to allocate space for it, and fails to zero initialize it. Since the EFI stub itself is allocated in the .init segment, which is in the middle of the image, its BSS section is not impacted by this, and the main consequence of this omission is that the BSS section may overlap with memory regions that are already used by the firmware. So let's warn about this condition, and force image reallocation to occur in this case, which works around the problem. Fixes: 82046702e288 ("efi/libstub/arm64: Replace 'preferred' offset with alignment check") Signed-off-by: Ard Biesheuvel Tested-by: Benjamin Herrenschmidt Signed-off-by: Sasha Levin

arm64: efi: kaslr: Fix occasional random alloc (and boot) failure

2021-08-18T07:07:02+00:00

[ Upstream commit 4152433c397697acc4b02c4a10d17d5859c2730d ] The EFI stub random allocator used for kaslr on arm64 has a subtle bug. In function get_entry_num_slots() which counts the number of possible allocation "slots" for the image in a given chunk of free EFI memory, "last_slot" can become negative if the chunk is smaller than the requested allocation size. The test "if (first_slot > last_slot)" doesn't catch it because both first_slot and last_slot are unsigned. I chose not to make them signed to avoid problems if this is ever used on architectures where there are meaningful addresses with the top bit set. Instead, fix it with an additional test against the allocation size. This can cause a boot failure in addition to a loss of randomisation due to another bug in the arm64 stub fixed separately. Signed-off-by: Benjamin Herrenschmidt Fixes: 2ddbfc81eac8 ("efi: stub: add implementation of efi_random_alloc()") Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin

efi/mokvar: Reserve the table only if it is in boot services data

2021-08-08T07:06:56+00:00

[ Upstream commit 47e1e233e9d822dfda068383fb9a616451bda703 ] One of the SUSE QA tests triggered: localhost kernel: efi: Failed to lookup EFI memory descriptor for 0x000000003dcf8000 which comes from x86's version of efi_arch_mem_reserve() trying to reserve a memory region. Usually, that function expects EFI_BOOT_SERVICES_DATA memory descriptors but the above case is for the MOKvar table which is allocated in the EFI shim as runtime services. That lead to a fix changing the allocation of that table to boot services. However, that fix broke booting SEV guests with that shim leading to this kernel fix 8d651ee9c71b ("x86/ioremap: Map EFI-reserved memory as encrypted for SEV") which extended the ioremap hint to map reserved EFI boot services as decrypted too. However, all that wasn't needed, IMO, because that error message in efi_arch_mem_reserve() was innocuous in this case - if the MOKvar table is not in boot services, then it doesn't need to be reserved in the first place because it is, well, in runtime services which *should* be reserved anyway. So do that reservation for the MOKvar table only if it is allocated in boot services data. I couldn't find any requirement about where that table should be allocated in, unlike the ESRT which allocation is mandated to be done in boot services data by the UEFI spec. Signed-off-by: Borislav Petkov Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin

firmware/efi: Tell memblock about EFI iomem reservations

2021-07-28T12:37:37+00:00

commit 2bab693a608bdf614b9fcd44083c5100f34b9f77 upstream. kexec_load_file() relies on the memblock infrastructure to avoid stamping over regions of memory that are essential to the survival of the system. However, nobody seems to agree how to flag these regions as reserved, and (for example) EFI only publishes its reservations in /proc/iomem for the benefit of the traditional, userspace based kexec tool. On arm64 platforms with GICv3, this can result in the payload being placed at the location of the LPI tables. Shock, horror! Let's augment the EFI reservation code with a memblock_reserve() call, protecting our dear tables from the secondary kernel invasion. Reported-by: Moritz Fischer Tested-by: Moritz Fischer Signed-off-by: Marc Zyngier Cc: stable@vger.kernel.org Cc: Ard Biesheuvel Cc: James Morse Cc: Catalin Marinas Cc: Will Deacon Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman

ACPI: utils: Fix reference counting in for_each_acpi_dev_match()

2021-07-28T12:37:30+00:00

[ Upstream commit 71f6428332844f38c7cb10461d9f29e9c9b983a0 ] Currently it's possible to iterate over the dangling pointer in case the device suddenly disappears. This may happen becase callers put it at the end of a loop. Instead, let's move that call inside acpi_dev_get_next_match_dev(). Fixes: 803abec64ef9 ("media: ipu3-cio2: Add cio2-bridge to ipu3-cio2 driver") Fixes: bf263f64e804 ("media: ACPI / bus: Add acpi_dev_get_next_match_dev() and helper macro") Fixes: edbd1bc4951e ("efi/dev-path-parser: Switch to use for_each_acpi_dev_match()") Signed-off-by: Andy Shevchenko Reviewed-by: Daniel Scally Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

efi/dev-path-parser: Switch to use for_each_acpi_dev_match()

2021-07-28T12:37:30+00:00

[ Upstream commit edbd1bc4951eff8da65732dbe0d381e555054428 ] Switch to use for_each_acpi_dev_match() instead of home grown analogue. No functional change intended. Signed-off-by: Andy Shevchenko Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin

efi/tpm: Differentiate missing and invalid final event log table.

2021-07-28T12:37:29+00:00

[ Upstream commit 674a9f1f6815849bfb5bf385e7da8fc198aaaba9 ] Missing TPM final event log table is not a firmware bug. Clearly if providing event log in the old format makes the final event log invalid it should not be provided at least in that case. Fixes: b4f1874c6216 ("tpm: check event log version before reading final events") Signed-off-by: Michal Suchanek Reviewed-by: Jarkko Sakkinen Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin

efi: cper: fix snprintf() use in cper_dimm_err_location()

2021-05-22T12:05:37+00:00

snprintf() should be given the full buffer size, not one less. And it guarantees nul-termination, so doing it manually afterwards is pointless. It's even potentially harmful (though probably not in practice because CPER_REC_LEN is 256), due to the "return how much would have been written had the buffer been big enough" semantics. I.e., if the bank and/or device strings are long enough that the "DIMM location ..." output gets truncated, writing to msg[n] is a buffer overflow. Signed-off-by: Rasmus Villemoes Fixes: 3760cd20402d4 ("CPER: Adjust code flow of some functions") Signed-off-by: Ard Biesheuvel