Intel OpenBMC Linux kernel source tree (mirror) https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-5.14-intel 2021-09-15T08:02:25+00:00 2021-09-15T08:02:25+00:00 Christophe JAILLET christophe.jaillet@wanadoo.fr 2021-08-06T06:46:11+00:00 urn:sha1:40c1cc3f3d0cecb6c5b05c70fa7dc903cf04ebdd [ Upstream commit 09cbd1df7d2615c19e40facbe31fdcb5f1ebfa96 ] The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add the corresponding 'put_device()' in the normal and error handling paths. Fixes: 4e3d60656a72 ("ARM: bcm2835: Add the Raspberry Pi firmware driver") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/5e17e5409b934cd08bf6f9279c73be5c1cb11cce.1628232242.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 2021-09-12T07:00:58+00:00 Hans de Goede hdegoede@redhat.com 2021-09-02T15:28:53+00:00 urn:sha1:9d1db6a315738823cca04a69616fe402c8b2db6e commit f97a2103f1a75ca70f23deadb4d96a16c4d85e7d upstream. Commit e26f023e01ef ("firmware/dmi: Include product_sku info to modalias") added a new field to the modalias in the middle of the modalias, breaking some existing udev/hwdb matches on the whole modalias without a wildcard ('*') in between the pvr and rvn fields. All modalias matches in e.g. : https://github.com/systemd/systemd/blob/main/hwdb.d/60-sensor.hwdb deliberately end in ':*' so that new fields can be added at *the end* of the modalias, but adding a new field in the middle like this breaks things. Move the new sku field to the end of the modalias to fix some hwdb entries no longer matching. The new sku field has already been put to use in 2 new hwdb entries: sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:sku0A3E:* ACCEL_LOCATION=base sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:sku0B0B:* ACCEL_LOCATION=base The wildcard use before and after the sku in these matches means that they should keep working with the sku moved to the end. Note that there is a second instance of in essence the same problem, commit f5152f4ded3c ("firmware/dmi: Report DMI Bios & EC firmware release") Added 2 new br and efr fields in the middle of the modalias. This too breaks some hwdb modalias matches, but this has gone unnoticed for over a year. So some newer hwdb modalias matches actually depend on these fields being in the middle of the string. Moving these to the end now would break 3 hwdb entries, while fixing 8 entries. Since there is no good answer for the new br and efr fields I have chosen to leave these as is. Instead I'll submit a hwdb update to put a wildcard at the place where these fields may or may not be present depending on the kernel version. BugLink: https://github.com/systemd/systemd/issues/20550 Link: https://github.com/systemd/systemd/pull/20562 Fixes: e26f023e01ef ("firmware/dmi: Include product_sku info to modalias") Cc: stable@vger.kernel.org Cc: Kai-Chuan Hsieh <kaichuan.hsieh@canonical.com> Cc: Erwan Velu <e.velu@criteo.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jean Delvare <jdelvare@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2021-08-15T16:38:26+00:00 Linus Torvalds torvalds@linux-foundation.org 2021-08-15T16:38:26+00:00 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:49+00:00 Thomas Gleixner tglx@linutronix.de 2021-08-10T08:24:49+00:00 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:13+00:00 Ard Biesheuvel ardb@kernel.org 2021-07-26T14:31:44+00:00 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:07+00:00 Ard Biesheuvel ardb@kernel.org 2021-07-26T14:24:01+00:00 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:02+00:00 Ard Biesheuvel ardb@kernel.org 2021-07-22T10:10:31+00:00 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:53+00:00 Ard Biesheuvel ardb@kernel.org 2021-07-26T09:38:41+00:00 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:18+00:00 Arnd Bergmann arnd@arndb.de 2021-08-02T12:35:17+00:00 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:27+00:00 Linus Torvalds torvalds@linux-foundation.org 2021-07-25T17:04:27+00:00 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.