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

efi: Accept version 2 of memory attributes table

2023-02-22T11:46:02+00:00

commit 636ab417a7aec4ee993916e688eb5c5977570836 upstream. UEFI v2.10 introduces version 2 of the memory attributes table, which turns the reserved field into a flags field, but is compatible with version 1 in all other respects. So let's not complain about version 2 if we encounter it. Cc: Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman

efi: random: Properly limit the size of the random seed

2022-12-08T10:16:33+00:00

Commit be36f9e7517e ("efi: READ_ONCE rng seed size before munmap") added a READ_ONCE() and also changed the call to add_bootloader_randomness() to use the local size variable. Neither of these changes was actually needed and this was not backported to the 4.14 stable branch. Commit 161a438d730d ("efi: random: reduce seed size to 32 bytes") reverted the addition of READ_ONCE() and added a limit to the value of size. This depends on the earlier commit, because size can now differ from seed->size, but it was wrongly backported to the 4.14 stable branch by itself. Apply the missing change to the add_bootloader_randomness() parameter (except that here we are still using add_device_randomness()). Fixes: 700485f70e50 ("efi: random: reduce seed size to 32 bytes") Signed-off-by: Ben Hutchings Signed-off-by: Greg Kroah-Hartman

efi: random: reduce seed size to 32 bytes

2022-11-10T14:47:23+00:00

commit 161a438d730dade2ba2b1bf8785f0759aba4ca5f upstream. We no longer need at least 64 bytes of random seed to permit the early crng init to complete. The RNG is now based on Blake2s, so reduce the EFI seed size to the Blake2s hash size, which is sufficient for our purposes. While at it, drop the READ_ONCE(), which was supposed to prevent size from being evaluated after seed was unmapped. However, this cannot actually happen, so READ_ONCE() is unnecessary here. Cc: # v4.14+ Signed-off-by: Ard Biesheuvel Reviewed-by: Jason A. Donenfeld Acked-by: Ilias Apalodimas Signed-off-by: Greg Kroah-Hartman

efi: libstub: drop pointless get_memory_map() call

2022-10-26T11:17:14+00:00

commit d80ca810f096ff66f451e7a3ed2f0cd9ef1ff519 upstream. Currently, the non-x86 stub code calls get_memory_map() redundantly, given that the data it returns is never used anywhere. So drop the call. Cc: # v4.14+ Fixes: 24d7c494ce46 ("efi/arm-stub: Round up FDT allocation to mapping size") Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman

efi: capsule-loader: Fix use-after-free in efi_capsule_write

2022-09-15T10:23:51+00:00

commit 9cb636b5f6a8cc6d1b50809ec8f8d33ae0c84c95 upstream. A race condition may occur if the user calls close() on another thread during a write() operation on the device node of the efi capsule. This is a race condition that occurs between the efi_capsule_write() and efi_capsule_flush() functions of efi_capsule_fops, which ultimately results in UAF. So, the page freeing process is modified to be done in efi_capsule_release() instead of efi_capsule_flush(). Cc: # v4.9+ Signed-off-by: Hyunwoo Kim Link: https://lore.kernel.org/all/20220907102920.GA88602@ubuntu/ Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman

efi: fix return value of __setup handlers

2022-03-23T08:01:35+00:00

[ Upstream commit 9feaf8b387ee0ece9c1d7add308776b502a35d0c ] When "dump_apple_properties" is used on the kernel boot command line, it causes an Unknown parameter message and the string is added to init's argument strings: Unknown kernel command line parameters "dump_apple_properties BOOT_IMAGE=/boot/bzImage-517rc6 efivar_ssdt=newcpu_ssdt", will be passed to user space. Run /sbin/init as init process with arguments: /sbin/init dump_apple_properties with environment: HOME=/ TERM=linux BOOT_IMAGE=/boot/bzImage-517rc6 efivar_ssdt=newcpu_ssdt Similarly when "efivar_ssdt=somestring" is used, it is added to the Unknown parameter message and to init's environment strings, polluting them (see examples above). Change the return value of the __setup functions to 1 to indicate that the __setup options have been handled. Fixes: 58c5475aba67 ("x86/efi: Retrieve and assign Apple device properties") Fixes: 475fb4e8b2f4 ("efi / ACPI: load SSTDs from EFI variables") Signed-off-by: Randy Dunlap Reported-by: Igor Zhbanov Link: lore.kernel.org/r/64644a2f-4a20-bab3-1e15-3b2cdd0defe3@omprussia.ru Cc: Ard Biesheuvel Cc: linux-efi@vger.kernel.org Cc: Lukas Wunner Cc: Octavian Purdila Cc: "Rafael J. Wysocki" Cc: Matt Fleming Link: https://lore.kernel.org/r/20220301041851.12459-1-rdunlap@infradead.org Signed-off-by: Ard Biesheuvel Signed-off-by: Sasha Levin

efivars: Respect "block" flag in efivar_entry_set_safe()

2022-03-08T18:01:58+00:00

commit 258dd902022cb10c83671176688074879517fd21 upstream. When the "block" flag is false, the old code would sometimes still call check_var_size(), which wrongly tells ->query_variable_store() that it can block. As far as I can tell, this can't really materialize as a bug at the moment, because ->query_variable_store only does something on X86 with generic EFI, and in that configuration we always take the efivar_entry_set_nonblocking() path. Fixes: ca0e30dcaa53 ("efi: Add nonblocking option to efi_query_variable_store()") Signed-off-by: Jann Horn Signed-off-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20220218180559.1432559-1-jannh@google.com Signed-off-by: Greg Kroah-Hartman

efi: Change down_interruptible() in virt_efi_reset_system() to down_trylock()

2021-10-20T08:42:03+00:00

commit 38fa3206bf441911258e5001ac8b6738693f8d82 upstream. While reboot the system by sysrq, the following bug will be occur. BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:90 in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 10052, name: rc.shutdown CPU: 3 PID: 10052 Comm: rc.shutdown Tainted: G W O 5.10.0 #1 Call trace: dump_backtrace+0x0/0x1c8 show_stack+0x18/0x28 dump_stack+0xd0/0x110 ___might_sleep+0x14c/0x160 __might_sleep+0x74/0x88 down_interruptible+0x40/0x118 virt_efi_reset_system+0x3c/0xd0 efi_reboot+0xd4/0x11c machine_restart+0x60/0x9c emergency_restart+0x1c/0x2c sysrq_handle_reboot+0x1c/0x2c __handle_sysrq+0xd0/0x194 write_sysrq_trigger+0xbc/0xe4 proc_reg_write+0xd4/0xf0 vfs_write+0xa8/0x148 ksys_write+0x6c/0xd8 __arm64_sys_write+0x18/0x28 el0_svc_common.constprop.3+0xe4/0x16c do_el0_svc+0x1c/0x2c el0_svc+0x20/0x30 el0_sync_handler+0x80/0x17c el0_sync+0x158/0x180 The reason for this problem is that irq has been disabled in machine_restart() and then it calls down_interruptible() in virt_efi_reset_system(), which would occur sleep in irq context, it is dangerous! Commit 99409b935c9a("locking/semaphore: Add might_sleep() to down_*() family") add might_sleep() in down_interruptible(), so the bug info is here. down_trylock() can solve this problem, cause there is no might_sleep. -------- Cc: Signed-off-by: Zhang Jianhua Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman

efi/cper: use stack buffer for error record decoding

2021-10-20T08:42:03+00:00

commit b3a72ca80351917cc23f9e24c35f3c3979d3c121 upstream. Joe reports that using a statically allocated buffer for converting CPER error records into human readable text is probably a bad idea. Even though we are not aware of any actual issues, a stack buffer is clearly a better choice here anyway, so let's move the buffer into the stack frames of the two functions that refer to it. Cc: Reported-by: Joe Perches Signed-off-by: Ard Biesheuvel Signed-off-by: Greg Kroah-Hartman

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

2021-06-10T10:43:49+00:00

[ Upstream commit 942859d969de7f6f7f2659a79237a758b42782da ] 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 Signed-off-by: Sasha Levin