Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ https://git.shady.money/linux/atom?h=v5.14 2021-08-15T16:38:26Z 2021-08-15T16:38:26Z Linus Torvalds torvalds@linux-foundation.org 2021-08-15T16:38:26Z urn:sha1:12aef8acf0991e8a4a5fe892067e2c8fc6760ace Pull EFI fixes from Borislav Petkov: "A batch of fixes for the arm64 stub image loader: - fix a logic bug that can make the random page allocator fail spuriously - force reallocation of the Image when it overlaps with firmware reserved memory regions - fix an oversight that defeated on optimization introduced earlier where images loaded at a suitable offset are never moved if booting without randomization - complain about images that were not loaded at the right offset by the firmware image loader" * tag 'efi_urgent_for_v5.14_rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi/libstub: arm64: Double check image alignment at entry efi/libstub: arm64: Warn when efi_random_alloc() fails efi/libstub: arm64: Relax 2M alignment again for relocatable kernels efi/libstub: arm64: Force Image reallocation if BSS was not reserved arm64: efi: kaslr: Fix occasional random alloc (and boot) failure 2021-08-10T08:24:49Z Thomas Gleixner tglx@linutronix.de 2021-08-10T08:24:49Z urn:sha1:55203550f9afb027389bd24ce85bd90044c3aa81 Pull EFI fixes from Ard Biesheuvel: A batch of fixes for the arm64 stub image loader: - fix a logic bug that can make the random page allocator fail spuriously - force reallocation of the Image when it overlaps with firmware reserved memory regions - fix an oversight that defeated on optimization introduced earlier where images loaded at a suitable offset are never moved if booting without randomization - complain about images that were not loaded at the right offset by the firmware image loader. Link: https://lore.kernel.org/r/20210803091215.2566-1-ardb@kernel.org 2021-08-03T05:43:13Z Ard Biesheuvel ardb@kernel.org 2021-07-26T14:31:44Z urn:sha1:c32ac11da3f83bb42b986702a9b92f0a14ed4182 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: <stable@vger.kernel.org> # v5.10+ Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> 2021-08-03T05:43:07Z Ard Biesheuvel ardb@kernel.org 2021-07-26T14:24:01Z urn:sha1:ff80ef5bf5bd59e5eab82d1d846acc613ebbf6c4 Randomization of the physical load address of the kernel image relies on efi_random_alloc() returning successfully, and currently, we ignore any failures and just carry on, using the ordinary, non-randomized page allocator routine. This means we never find out if a failure occurs, which could harm security, so let's at least warn about this condition. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> 2021-08-03T05:43:02Z Ard Biesheuvel ardb@kernel.org 2021-07-22T10:10:31Z urn:sha1: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 <ardb@kernel.org> Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> 2021-08-03T05:41:53Z Ard Biesheuvel ardb@kernel.org 2021-07-26T09:38:41Z urn:sha1: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 <ardb@kernel.org> Tested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> 2021-08-02T12:35:18Z Arnd Bergmann arnd@arndb.de 2021-08-02T12:35:17Z urn:sha1:64429b9e0e1dc05cbe4f88076909fe0c4d2d29dc tee: Improve support for kexec and kdump This fixes several bugs uncovered while exercising the OP-TEE, ftpm (firmware TPM), and tee_bnxt_fw (Broadcom BNXT firmware manager) drivers with kexec and kdump (emergency kexec) based workflows. * tag 'tee-kexec-fixes-for-v5.14' of git://git.linaro.org:/people/jens.wiklander/linux-tee: firmware: tee_bnxt: Release TEE shm, session, and context during kexec tpm_ftpm_tee: Free and unregister TEE shared memory during kexec tee: Correct inappropriate usage of TEE_SHM_DMA_BUF flag tee: add tee_shm_alloc_kernel_buf() optee: Clear stale cache entries during initialization optee: fix tee out of memory failure seen during kexec reboot optee: Refuse to load the driver under the kdump kernel optee: Fix memory leak when failing to register shm pages Link: https://lore.kernel.org/r/20210726081039.GA2482361@jade Signed-off-by: Arnd Bergmann <arnd@arndb.de> 2021-07-25T17:04:27Z Linus Torvalds torvalds@linux-foundation.org 2021-07-25T17:04:27Z urn:sha1:e049597e7ec11fdc276d787d320b01ef1f647c4a Pull EFI fixes from Thomas Gleixner: "A set of EFI fixes: - Prevent memblock and I/O reserved resources to get out of sync when EFI memreserve is in use. - Don't claim a non-existing table is invalid - Don't warn when firmware memory is already reserved correctly" * tag 'efi-urgent-2021-07-25' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi/mokvar: Reserve the table only if it is in boot services data efi/libstub: Fix the efi_load_initrd function description firmware/efi: Tell memblock about EFI iomem reservations efi/tpm: Differentiate missing and invalid final event log table. 2021-07-21T05:55:50Z Allen Pais apais@linux.microsoft.com 2021-06-14T22:33:17Z urn:sha1:914ab19e471d8fb535ed50dff108b0a615f3c2d8 Implement a .shutdown hook that will be called during a kexec operation so that the TEE shared memory, session, and context that were set up during .probe can be properly freed/closed. Additionally, don't use dma-buf backed shared memory for the fw_shm_pool. dma-buf backed shared memory cannot be reliably freed and unregistered during a kexec operation even when tee_shm_free() is called on the shm from a .shutdown hook. The problem occurs because dma_buf_put() calls fput() which then uses task_work_add(), with the TWA_RESUME parameter, to queue tee_shm_release() to be called before the current task returns to user mode. However, the current task never returns to user mode before the kexec completes so the memory is never freed nor unregistered. Use tee_shm_alloc_kernel_buf() to avoid dma-buf backed shared memory allocation so that tee_shm_free() can directly call tee_shm_release(). This will ensure that the shm can be freed and unregistered during a kexec operation. Fixes: 246880958ac9 ("firmware: broadcom: add OP-TEE based BNXT f/w manager") Cc: stable@vger.kernel.org Signed-off-by: Allen Pais <apais@linux.microsoft.com> Co-developed-by: Tyler Hicks <tyhicks@linux.microsoft.com> Signed-off-by: Tyler Hicks <tyhicks@linux.microsoft.com> Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Acked-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org> 2021-07-20T14:49:48Z Benjamin Herrenschmidt benh@kernel.crashing.org 2021-07-20T11:14:05Z urn:sha1: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 <benh@kernel.crashing.org> Fixes: 2ddbfc81eac8 ("efi: stub: add implementation of efi_random_alloc()") Signed-off-by: Ard Biesheuvel <ardb@kernel.org>