summaryrefslogtreecommitdiffstats
path: root/drivers/firmware
Commit message (Collapse)AuthorAgeFilesLines
* efi: Change down_interruptible() in virt_efi_reset_system() to down_trylock()Zhang Jianhua2021-10-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: <stable@vger.kernel.org> Signed-off-by: Zhang Jianhua <chris.zjh@huawei.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* efi/cper: use stack buffer for error record decodingArd Biesheuvel2021-10-201-2/+2
| | | | | | | | | | | | | | | 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: <stable@vger.kernel.org> Reported-by: Joe Perches <joe@perches.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* firmware: arm_scmi: Add delayed response status checkCristian Marussi2021-08-081-2/+6
| | | | | | | | | | | | | | | commit f1748b1ee1fa0fd1a074504045b530b62f949188 upstream. A successfully received delayed response could anyway report a failure at the protocol layer in the message status field. Add a check also for this error condition. Link: https://lore.kernel.org/r/20210608103056.3388-1-cristian.marussi@arm.com Fixes: 58ecdf03dbb9 ("firmware: arm_scmi: Add support for asynchronous commands and delayed response") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* firmware: arm_scmi: Ensure drivers provide a probe functionSudeep Holla2021-08-081-0/+3
| | | | | | | | | | | | | | | | | commit 5e469dac326555d2038d199a6329458cc82a34e5 upstream. The bus probe callback calls the driver callback without further checking. Better be safe than sorry and refuse registration of a driver without a probe function to prevent a NULL pointer exception. Link: https://lore.kernel.org/r/20210624095059.4010157-2-sudeep.holla@arm.com Fixes: 933c504424a2 ("firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices") Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Tested-by: Cristian Marussi <cristian.marussi@arm.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* firmware: arm_scmi: Fix range check for the maximum number of pending messagesCristian Marussi2021-07-311-2/+3
| | | | | | | | | | | | | | | | | | [ Upstream commit bdb8742dc6f7c599c3d61959234fe4c23638727b ] SCMI message headers carry a sequence number and such field is sized to allow for MSG_TOKEN_MAX distinct numbers; moreover zero is not really an acceptable maximum number of pending in-flight messages. Fix accordingly the checks performed on the value exported by transports in scmi_desc.max_msg Link: https://lore.kernel.org/r/20210712141833.6628-3-cristian.marussi@arm.com Reported-by: Vincent Guittot <vincent.guittot@linaro.org> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> [sudeep.holla: updated the patch title and error message] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: arm_scmi: Fix possible scmi_linux_errmap buffer overflowSudeep Holla2021-07-311-3/+4
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit 7a691f16ccad05d770f813d9c4b4337a30c6d63f ] The scmi_linux_errmap buffer access index is supposed to depend on the array size to prevent element out of bounds access. It uses SCMI_ERR_MAX to check bounds but that can mismatch with the array size. It also changes the success into -EIO though scmi_linux_errmap is never used in case of success, it is expected to work for success case too. It is slightly confusing code as the negative of the error code is used as index to the buffer. Fix it by negating it at the start and make it more readable. Link: https://lore.kernel.org/r/20210707135028.1869642-1-sudeep.holla@arm.com Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware/efi: Tell memblock about EFI iomem reservationsMarc Zyngier2021-07-281-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <mdf@kernel.org> Tested-by: Moritz Fischer <mdf@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Cc: Ard Biesheuvel <ardb@kernel.org> Cc: James Morse <james.morse@arm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* efi/tpm: Differentiate missing and invalid final event log table.Michal Suchanek2021-07-281-3/+5
| | | | | | | | | | | | | | | [ 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 <msuchanek@suse.de> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: turris-mox-rwtm: add marvell,armada-3700-rwtm-firmware compatible ↵Pali Rohár2021-07-251-0/+1
| | | | | | | | | | | | | | | | | string [ Upstream commit 90ae47215de3fec862aeb1a0f0e28bb505ab1351 ] Add more generic compatible string 'marvell,armada-3700-rwtm-firmware' for this driver, since it can also be used on other Armada 3720 devices. Current compatible string 'cznic,turris-mox-rwtm' is kept for backward compatibility. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: tegra: bpmp: Fix Tegra234-only buildsThierry Reding2021-07-253-2/+5
| | | | | | | | | | [ Upstream commit bd778b893963d67d7eb01f49d84ffcd3eaf229dd ] The tegra186_bpmp_ops symbol is used on Tegra234, so make sure it's available. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: turris-mox-rwtm: fail probing when firmware does not support hwrngPali Rohár2021-07-201-0/+28
| | | | | | | | | | | | | | | | | | | [ Upstream commit 2eab59cf0d2036a5a9e264f719b71c21ccf679c2 ] When Marvell's rWTM firmware, which does not support the GET_RANDOM command, is used, kernel prints an error message hwrng: no data available every 10 seconds. Fail probing of this driver if the rWTM firmware does not support the GET_RANDOM command. Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: turris-mox-rwtm: report failures betterMarek Behún2021-07-201-6/+12
| | | | | | | | | | | | | | | | | [ Upstream commit 72f99888944c44de1c899bbe44db1e53bdc9d994 ] Report a notice level message if a command is not supported by the rWTM firmware. This should not be an error, merely a notice, because the firmware can be used on boards that do not have manufacturing information burned. Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: turris-mox-rwtm: fix reply status decoding functionMarek Behún2021-07-201-2/+5
| | | | | | | | | | | | | | | | | | [ Upstream commit e34e60253d9272311831daed8a2d967cf80ca3dc ] The status decoding function mox_get_status() currently contains an incorrect check: if the error status is not MBOX_STS_SUCCESS, it always returns -EIO, so the comparison to MBOX_STS_FAIL is never executed and we don't get the actual error code sent by the firmware. Fix this. Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: arm_scmi: Reset Rx buffer to max size during async commandsCristian Marussi2021-07-201-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 0cb7af474e0dbb2f500c67aa62b6db9fafa74de2 ] During an async commands execution the Rx buffer length is at first set to max_msg_sz when the synchronous part of the command is first sent. However once the synchronous part completes the transport layer waits for the delayed response which will be processed using the same xfer descriptor initially allocated. Since synchronous response received at the end of the xfer will shrink the Rx buffer length to the effective payload response length, it needs to be reset again. Raise the Rx buffer length again to max_msg_sz before fetching the delayed response to ensure full response is read correctly from the shared memory. Link: https://lore.kernel.org/r/20210601102421.26581-2-cristian.marussi@arm.com Fixes: 58ecdf03dbb9 ("firmware: arm_scmi: Add support for asynchronous commands and delayed response") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> [sudeep.holla: moved reset to scmi_handle_response as it could race with do_xfer_with_response] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: tegra: Fix error return code in tegra210_bpmp_init()Zhen Lei2021-07-201-1/+1
| | | | | | | | | | | | | | [ Upstream commit 7fea67710e9f6a111a2c9440576f2396ccd92d57 ] When call irq_get_irq_data() to get the IRQ's irq_data failed, an appropriate error code -ENOENT should be returned. However, we directly return 'err', which records the IRQ number instead of the error code. Fixes: 139251fc2208 ("firmware: tegra: add bpmp driver for Tegra210") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* qemu_fw_cfg: Make fw_cfg_rev_attr a proper kobj_attributeNathan Chancellor2021-07-191-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit fca41af18e10318e4de090db47d9fa7169e1bf2f upstream. fw_cfg_showrev() is called by an indirect call in kobj_attr_show(), which violates clang's CFI checking because fw_cfg_showrev()'s second parameter is 'struct attribute', whereas the ->show() member of 'struct kobj_structure' expects the second parameter to be of type 'struct kobj_attribute'. $ cat /sys/firmware/qemu_fw_cfg/rev 3 $ dmesg | grep "CFI failure" [ 26.016832] CFI failure (target: fw_cfg_showrev+0x0/0x8): Fix this by converting fw_cfg_rev_attr to 'struct kobj_attribute' where this would have been caught automatically by the incompatible pointer types compiler warning. Update fw_cfg_showrev() accordingly. Fixes: 75f3e8e47f38 ("firmware: introduce sysfs driver for QEMU's fw_cfg device") Link: https://github.com/ClangBuiltLinux/linux/issues/1299 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210211194258.4137998-1-nathan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* firmware: stratix10-svc: Fix a resource leak in an error handling pathChristophe JAILLET2021-07-141-7/+15
| | | | | | | | | | | | | | | | | [ Upstream commit d99247f9b542533ddbf87a3481a05473b8e48194 ] If an error occurs after a successful 'kfifo_alloc()' call, it must be undone by a corresponding 'kfifo_free()' call, as already done in the remove function. While at it, move the 'platform_device_put()' call to this new error handling path and explicitly return 0 in the success path. Fixes: b5dc75c915cd ("firmware: stratix10-svc: extend svc to support new RSU features") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/0ca3f3ab139c53e846804455a1e7599ee8ae896a.1621621271.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* efi: cper: fix snprintf() use in cper_dimm_err_location()Rasmus Villemoes2021-06-101-3/+1
| | | | | | | | | | | | | | | | | | | [ 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 <linux@rasmusvillemoes.dk> Fixes: 3760cd20402d4 ("CPER: Adjust code flow of some functions") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* efi: Allow EFI_MEMORY_XP and EFI_MEMORY_RO both to be clearedHeiner Kallweit2021-06-101-5/+0
| | | | | | | | | | | | | | [ Upstream commit 45add3cc99feaaf57d4b6f01d52d532c16a1caee ] UEFI spec 2.9, p.108, table 4-1 lists the scenario that both attributes are cleared with the description "No memory access protection is possible for Entry". So we can have valid entries where both attributes are cleared, so remove the check. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Fixes: 10f0d2f577053 ("efi: Implement generic support for the Memory Attributes table") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: arm_scpi: Prevent the ternary sign expansion bugDan Carpenter2021-05-261-1/+3
| | | | | | | | | | | | | | | | | | | | | | [ Upstream commit d9cd78edb2e6b7e26747c0ec312be31e7ef196fe ] How the type promotion works in ternary expressions is a bit tricky. The problem is that scpi_clk_get_val() returns longs, "ret" is a int which holds a negative error code, and le32_to_cpu() is an unsigned int. We want the negative error code to be cast to a negative long. But because le32_to_cpu() is an u32 then "ret" is type promoted to u32 and becomes a high positive and then it is promoted to long and it is still a high positive value. Fix this by getting rid of the ternary. Link: https://lore.kernel.org/r/YIE7pdqV/h10tEAK@mwanda Fixes: 8cb7cf56c9fe ("firmware: add support for ARM System Control and Power Interface(SCPI) protocol") Reviewed-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> [sudeep.holla: changed to return 0 as clock rate on error] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: qcom-scm: Fix QCOM_SCM configurationHe Ying2021-05-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 2954a6f12f250890ec2433cec03ba92784d613e8 ] When CONFIG_QCOM_SCM is y and CONFIG_HAVE_ARM_SMCCC is not set, compiling errors are encountered as follows: drivers/firmware/qcom_scm-smc.o: In function `__scm_smc_do_quirk': qcom_scm-smc.c:(.text+0x36): undefined reference to `__arm_smccc_smc' drivers/firmware/qcom_scm-legacy.o: In function `scm_legacy_call': qcom_scm-legacy.c:(.text+0xe2): undefined reference to `__arm_smccc_smc' drivers/firmware/qcom_scm-legacy.o: In function `scm_legacy_call_atomic': qcom_scm-legacy.c:(.text+0x1f0): undefined reference to `__arm_smccc_smc' Note that __arm_smccc_smc is defined when HAVE_ARM_SMCCC is y. So add dependency on HAVE_ARM_SMCCC in QCOM_SCM configuration. Fixes: 916f743da354 ("firmware: qcom: scm: Move the scm driver to drivers/firmware") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: He Ying <heying24@huawei.com> Link: https://lore.kernel.org/r/20210406094200.60952-1-heying24@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware/efi: Fix a use after bug in efi_mem_reserve_persistentLv Yunlong2021-03-241-1/+2
| | | | | | | | | | | | | commit 9ceee7d0841a8f7d7644021ba7d4cc1fbc7966e3 upstream. In the for loop in efi_mem_reserve_persistent(), prsv = rsv->next use the unmapped rsv. Use the unmapped pages will cause segment fault. Fixes: 18df7577adae6 ("efi/memreserve: deal with memreserve entries in unmapped memory") Signed-off-by: Lv Yunlong <lyl2019@mail.ustc.edu.cn> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* firmware: imx: select SOC_BUS to fix firmware buildRandy Dunlap2021-02-031-0/+1
| | | | | | | | | | | | | | | | | | | | | [ Upstream commit 82c082784e03a9a9c043345f9bc04bc8254cf6da ] Fix build error in firmware/imx/ selecting SOC_BUS. riscv32-linux-ld: drivers/firmware/imx/imx-scu-soc.o: in function `.L9': imx-scu-soc.c:(.text+0x1b0): undefined reference to `soc_device_register' Fixes: edbee095fafb ("firmware: imx: add SCU firmware driver support") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Atish Patra <atish.patra@wdc.com> Cc: Palmer Dabbelt <palmerdabbelt@google.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Anson Huang <Anson.Huang@nxp.com> Cc: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* efi: EFI_EARLYCON should depend on EFIGeert Uytterhoeven2020-12-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 36a237526cd81ff4b6829e6ebd60921c6f976e3b ] CONFIG_EFI_EARLYCON defaults to yes, and thus is enabled on systems that do not support EFI, or do not have EFI support enabled, but do satisfy the symbol's other dependencies. While drivers/firmware/efi/ won't be entered during the build phase if CONFIG_EFI=n, and drivers/firmware/efi/earlycon.c itself thus won't be built, enabling EFI_EARLYCON does force-enable CONFIG_FONT_SUPPORT and CONFIG_ARCH_USE_MEMREMAP_PROT, and CONFIG_FONT_8x16, which is undesirable. Fix this by making CONFIG_EFI_EARLYCON depend on CONFIG_EFI. This reduces kernel size on headless systems by more than 4 KiB. Fixes: 69c1f396f25b805a ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation") Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Link: https://lore.kernel.org/r/20201124191646.3559757-1-geert@linux-m68k.org Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: arm_scmi: Add missing Rx size re-initialisationSudeep Holla2020-11-056-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 9724722fde8f9bbd2b87340f00b9300c9284001e ] Few commands provide the list of description partially and require to be called consecutively until all the descriptors are fetched completely. In such cases, we don't release the buffers and reuse them for consecutive transmits. However, currently we don't reset the Rx size which will be set as per the response for the last transmit. This may result in incorrect response size being interpretted as the firmware may repond with size greater than the one set but we read only upto the size set by previous response. Let us reset the receive buffer size to max possible in such cases as we don't know the exact size of the response. Link: https://lore.kernel.org/r/20201012141746.32575-1-sudeep.holla@arm.com Fixes: b6f20ff8bd94 ("firmware: arm_scmi: add common infrastructure and support for base protocol") Reported-by: Etienne Carriere <etienne.carriere@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: arm_scmi: Fix ARCH_COLD_RESETEtienne Carriere2020-11-051-3/+1
| | | | | | | | | | | | | [ Upstream commit 45b9e04d5ba0b043783dfe2b19bb728e712cb32e ] The defination for ARCH_COLD_RESET is wrong. Let us fix it according to the SCMI specification. Link: https://lore.kernel.org/r/20201008143722.21888-5-etienne.carriere@linaro.org Fixes: 95a15d80aa0d ("firmware: arm_scmi: Add RESET protocol in SCMI v2.0") Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: arm_sdei: Use cpus_read_lock() to avoid races with cpuhpJames Morse2020-10-011-12/+14
| | | | | | | | | | | | | | | | | | | | [ Upstream commit 54f529a6806c9710947a4f2cdc15d6ea54121ccd ] SDEI has private events that need registering and enabling on each CPU. CPUs can come and go while we are trying to do this. SDEI tries to avoid these problems by setting the reregister flag before the register call, so any CPUs that come online register the event too. Sticking plaster like this doesn't work, as if the register call fails, a CPU that subsequently comes online will register the event before reregister is cleared. Take cpus_read_lock() around the register and enable calls. We don't want surprise CPUs to do the wrong thing if they race with these calls failing. Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* efi: add missed destroy_workqueue when efisubsys_init failsLi Heng2020-08-261-0/+2
| | | | | | | | | | | | | | | commit 98086df8b70c06234a8f4290c46064e44dafa0ed upstream. destroy_workqueue() should be called to destroy efi_rts_wq when efisubsys_init() init resources fails. Cc: <stable@vger.kernel.org> Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Li Heng <liheng40@huawei.com> Link: https://lore.kernel.org/r/1595229738-10087-1-git-send-email-liheng40@huawei.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* firmware: arm_scmi: Fix SCMI genpd domain probingCristian Marussi2020-08-191-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit e0f1a30cf184821499eeb67daedd7a3f21bbcb0b ] When, at probe time, an SCMI communication failure inhibits the capacity to query power domains states, such domains should be skipped. Registering partially initialized SCMI power domains with genpd will causes kernel panic. arm-scmi timed out in resp(caller: scmi_power_state_get+0xa4/0xd0) scmi-power-domain scmi_dev.2: failed to get state for domain 9 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000009f3691000 [0000000000000000] pgd=00000009f1ca0003, p4d=00000009f1ca0003, pud=00000009f35ea003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP CPU: 2 PID: 381 Comm: bash Not tainted 5.8.0-rc1-00011-gebd118c2cca8 #2 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Jan 3 2020 Internal error: Oops: 96000006 [#1] PREEMPT SMP pstate: 80000005 (Nzcv daif -PAN -UAO BTYPE=--) pc : of_genpd_add_provider_onecell+0x98/0x1f8 lr : of_genpd_add_provider_onecell+0x48/0x1f8 Call trace: of_genpd_add_provider_onecell+0x98/0x1f8 scmi_pm_domain_probe+0x174/0x1e8 scmi_dev_probe+0x90/0xe0 really_probe+0xe4/0x448 driver_probe_device+0xfc/0x168 device_driver_attach+0x7c/0x88 bind_store+0xe8/0x128 drv_attr_store+0x2c/0x40 sysfs_kf_write+0x4c/0x60 kernfs_fop_write+0x114/0x230 __vfs_write+0x24/0x50 vfs_write+0xbc/0x1e0 ksys_write+0x70/0xf8 __arm64_sys_write+0x24/0x30 el0_svc_common.constprop.3+0x94/0x160 do_el0_svc+0x2c/0x98 el0_sync_handler+0x148/0x1a8 el0_sync+0x158/0x180 Do not register any power domain that failed to be queried with genpd. Fixes: 898216c97ed2 ("firmware: arm_scmi: add device power domain support using genpd") Link: https://lore.kernel.org/r/20200619220330.12217-1-cristian.marussi@arm.com Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: Fix a reference count leak.Qiushi Wu2020-08-111-3/+4
| | | | | | | | | | | | | | | [ Upstream commit fe3c60684377d5ad9b0569b87ed3e26e12c8173b ] kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Callback function fw_cfg_sysfs_release_entry() in kobject_put() can handle the pointer "entry" properly. Signed-off-by: Qiushi Wu <wu000273@umn.edu> Link: https://lore.kernel.org/r/20200613190533.15712-1-wu000273@umn.edu Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* drivers/firmware/psci: Fix memory leakage in alloc_init_cpu_groups()Gavin Shan2020-07-291-1/+4
| | | | | | | | | | | | | | | [ Upstream commit c377e67c6271954969384f9be1b1b71de13eba30 ] The CPU mask (@tmp) should be released on failing to allocate @cpu_groups or any of its elements. Otherwise, it leads to memory leakage because the CPU mask variable is dynamically allocated when CONFIG_CPUMASK_OFFSTACK is enabled. Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Link: https://lore.kernel.org/r/20200630075227.199624-1-gshan@redhat.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* efi: Make it possible to disable efivar_ssdt entirelyPeter Jones2020-07-092-1/+12
| | | | | | | | | | | | | | | | | | | | | commit 435d1a471598752446a72ad1201b3c980526d869 upstream. In most cases, such as CONFIG_ACPI_CUSTOM_DSDT and CONFIG_ACPI_TABLE_UPGRADE, boot-time modifications to firmware tables are tied to specific Kconfig options. Currently this is not the case for modifying the ACPI SSDT via the efivar_ssdt kernel command line option and associated EFI variable. This patch adds CONFIG_EFI_CUSTOM_SSDT_OVERLAYS, which defaults disabled, in order to allow enabling or disabling that feature during the build. Cc: <stable@vger.kernel.org> Signed-off-by: Peter Jones <pjones@redhat.com> Link: https://lore.kernel.org/r/20200615202408.2242614-1-pjones@redhat.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* efi/esrt: Fix reference count leak in esre_create_sysfs_entry.Qiushi Wu2020-06-301-1/+1
| | | | | | | | | | | | | | | [ Upstream commit 4ddf4739be6e375116c375f0a68bf3893ffcee21 ] kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Previous commit "b8eb718348b8" fixed a similar problem. Fixes: 0bb549052d33 ("efi: Add esrt support") Signed-off-by: Qiushi Wu <wu000273@umn.edu> Link: https://lore.kernel.org/r/20200528183804.4497-1-wu000273@umn.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: imx: scu: Fix possible memory leak in imx_scu_probe()Wei Yongjun2020-06-241-0/+1
| | | | | | | | | | | | | | [ Upstream commit 89f12d6509bff004852c51cb713a439a86816b24 ] 'chan_name' is malloced in imx_scu_probe() and should be freed before leaving from the error handling cases, otherwise it will cause memory leak. Fixes: edbee095fafb ("firmware: imx: add SCU firmware driver support") Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: qcom_scm: fix bogous abuse of dma-direct internalsChristoph Hellwig2020-06-241-6/+3
| | | | | | | | | | | | | | | | | | [ Upstream commit 459b1f86f1cba7de813fbc335df476c111feec22 ] As far as the device is concerned the dma address is the physical address. There is no need to convert it to a physical address, especially not using dma-direct internals that are not available to drivers and which will interact badly with IOMMUs. Last but not least the commit introducing it claimed to just fix a type issue, but actually changed behavior. Fixes: 6e37ccf78a532 ("firmware: qcom_scm: Use proper types for dma mappings") Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20200414123136.441454-1-hch@lst.de Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* efi/libstub/x86: Work around LLVM ELF quirk build regressionArd Biesheuvel2020-06-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit f77767ed5f4d398b29119563155e4ece2dfeee13 ] When building the x86 EFI stub with Clang, the libstub Makefile rules that manipulate the ELF object files may throw an error like: STUBCPY drivers/firmware/efi/libstub/efi-stub-helper.stub.o strip: drivers/firmware/efi/libstub/efi-stub-helper.stub.o: Failed to find link section for section 10 objcopy: drivers/firmware/efi/libstub/efi-stub-helper.stub.o: Failed to find link section for section 10 This is the result of a LLVM feature [0] where symbol references are stored in a LLVM specific .llvm_addrsig section in a non-transparent way, causing generic ELF tools such as strip or objcopy to choke on them. So force the compiler not to emit these sections, by passing the appropriate command line option. [0] https://sourceware.org/bugzilla/show_bug.cgi?id=23817 Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Peter Collingbourne <pcc@google.com> Cc: Sami Tolvanen <samitolvanen@google.com> Reported-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: Fangrui Song <maskray@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: imx: scu: Fix corruption of headerFranck LENORMAND2020-06-171-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit f5f27b79eab80de0287c243a22169e4876b08d5e ] The header of the message to send can be changed if the response is longer than the request: - 1st word, the header is sent - the remaining words of the message are sent - the response is received asynchronously during the execution of the loop, changing the size field in the header - the for loop test the termination condition using the corrupted header It is the case for the API build_info which has just a header as request but 3 words in response. This issue is fixed storing the header locally instead of using a pointer on it. Fixes: edbee095fafb (firmware: imx: add SCU firmware driver support) Signed-off-by: Franck LENORMAND <franck.lenormand@nxp.com> Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Cc: stable@vger.kernel.org Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: imx-scu: Support one TX and one RXPeng Fan2020-06-171-11/+43
| | | | | | | | | | | | | | | [ Upstream commit f25a066d1a07affb7bea4e5d9c179c3338338e23 ] Current imx-scu requires four TX and four RX to communicate with SCU. This is low efficient and causes lots of mailbox interrupts. With imx-mailbox driver could support one TX to use all four transmit registers and one RX to use all four receive registers, imx-scu could use one TX and one RX. Signed-off-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: imx: warn on unexpected RXLeonard Crestez2020-06-171-1/+9
| | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit cf0fd404455ce13850cc15423a3c2958933de384 ] The imx_scu_call_rpc function returns the result inside the same "msg" struct containing the transmitted message. This is implemented by holding a pointer to msg (which is usually on the stack) in sc_imx_rpc and writing to it from imx_scu_rx_callback. This means that if the have_resp parameter is incorrect or SCU sends an unexpected response for any reason the most likely result is kernel stack corruption. Fix this by only setting sc_imx_rpc.msg for the duration of the imx_scu_call_rpc call and warning in imx_scu_rx_callback if unset. Print the unexpected response data to help debugging. Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Acked-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* efi/efivars: Add missing kobject_put() in sysfs entry creation error pathArd Biesheuvel2020-06-171-1/+3
| | | | | | | | | | | | | | commit d8bd8c6e2cfab8b78b537715255be8d7557791c0 upstream. The documentation provided by kobject_init_and_add() clearly spells out the need to call kobject_put() on the kobject if an error is returned. Add this missing call to the error path. Cc: <stable@vger.kernel.org> Reported-by: 亿一 <teroincn@gmail.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* tpm: check event log version before reading final eventsLoïc Yhuel2020-05-272-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit b4f1874c62168159fdb419ced4afc77c1b51c475 ] This fixes the boot issues since 5.3 on several Dell models when the TPM is enabled. Depending on the exact grub binary, booting the kernel would freeze early, or just report an error parsing the final events log. We get an event log in the SHA-1 format, which doesn't have a tcg_efi_specid_event_head in the first event, and there is a final events table which doesn't match the crypto agile format. __calc_tpm2_event_size reads bad "count" and "efispecid->num_algs", and either fails, or loops long enough for the machine to be appear frozen. So we now only parse the final events table, which is per the spec always supposed to be in the crypto agile format, when we got a event log in this format. Fixes: c46f3405692de ("tpm: Reserve the TPM final events table") Fixes: 166a2809d65b2 ("tpm: Don't duplicate events from the final event log in the TCG2 log") Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1779611 Signed-off-by: Loïc Yhuel <loic.yhuel@gmail.com> Link: https://lore.kernel.org/r/20200512040113.277768-1-loic.yhuel@gmail.com Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Reviewed-by: Matthew Garrett <mjg59@google.com> [ardb: warn when final events table is missing or in the wrong format] Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
* gcc-10: mark more functions __init to avoid section mismatch warningsLinus Torvalds2020-05-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | commit e99332e7b4cda6e60f5b5916cf9943a79dbef902 upstream. It seems that for whatever reason, gcc-10 ends up not inlining a couple of functions that used to be inlined before. Even if they only have one single callsite - it looks like gcc may have decided that the code was unlikely, and not worth inlining. The code generation difference is harmless, but caused a few new section mismatch errors, since the (now no longer inlined) function wasn't in the __init section, but called other init functions: Section mismatch in reference from the function kexec_free_initrd() to the function .init.text:free_initrd_mem() Section mismatch in reference from the function tpm2_calc_event_log_size() to the function .init.text:early_memremap() Section mismatch in reference from the function tpm2_calc_event_log_size() to the function .init.text:early_memunmap() So add the appropriate __init annotation to make modpost not complain. In both cases there were trivially just a single callsite from another __init function. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* efi/x86: Ignore the memory attributes table on i386Ard Biesheuvel2020-04-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit dd09fad9d2caad2325a39b766ce9e79cfc690184 ] Commit: 3a6b6c6fb23667fa ("efi: Make EFI_MEMORY_ATTRIBUTES_TABLE initialization common across all architectures") moved the call to efi_memattr_init() from ARM specific to the generic EFI init code, in order to be able to apply the restricted permissions described in that table on x86 as well. We never enabled this feature fully on i386, and so mapping and reserving this table is pointless. However, due to the early call to memblock_reserve(), the memory bookkeeping gets confused to the point where it produces the splat below when we try to map the memory later on: ------------[ cut here ]------------ ioremap on RAM at 0x3f251000 - 0x3fa1afff WARNING: CPU: 0 PID: 0 at arch/x86/mm/ioremap.c:166 __ioremap_caller ... Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.20.0 #48 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 EIP: __ioremap_caller.constprop.0+0x249/0x260 Code: 90 0f b7 05 4e 38 40 de 09 45 e0 e9 09 ff ff ff 90 8d 45 ec c6 05 ... EAX: 00000029 EBX: 00000000 ECX: de59c228 EDX: 00000001 ESI: 3f250fff EDI: 00000000 EBP: de3edf20 ESP: de3edee0 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00200296 CR0: 80050033 CR2: ffd17000 CR3: 1e58c000 CR4: 00040690 Call Trace: ioremap_cache+0xd/0x10 ? old_map_region+0x72/0x9d old_map_region+0x72/0x9d efi_map_region+0x8/0xa efi_enter_virtual_mode+0x260/0x43b start_kernel+0x329/0x3aa i386_start_kernel+0xa7/0xab startup_32_smp+0x164/0x168 ---[ end trace e15ccf6b9f356833 ]--- Let's work around this by disregarding the memory attributes table altogether on i386, which does not result in a loss of functionality or protection, given that we never consumed the contents. Fixes: 3a6b6c6fb23667fa ("efi: Make EFI_MEMORY_ATTRIBUTES_TABLE ... ") Tested-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200304165917.5893-1-ardb@kernel.org Link: https://lore.kernel.org/r/20200308080859.21568-21-ardb@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
* firmware: arm_sdei: fix double-lock on hibernate with shared eventsJames Morse2020-04-171-17/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | [ Upstream commit 6ded0b61cf638bf9f8efe60ab8ba23db60ea9763 ] SDEI has private events that must be registered on each CPU. When CPUs come and go they must re-register and re-enable their private events. Each event has flags to indicate whether this should happen to protect against an event being registered on a CPU coming online, while all the others are unregistering the event. These flags are protected by the sdei_list_lock spinlock, because the cpuhp callbacks can't take the mutex. Hibernate needs to unregister all events, but keep the in-memory re-register and re-enable as they are. sdei_unregister_shared() takes the spinlock to walk the list, then calls _sdei_event_unregister() on each shared event. _sdei_event_unregister() tries to take the same spinlock to update re-register and re-enable. This doesn't go so well. Push the re-register and re-enable updates out to their callers. sdei_unregister_shared() doesn't want these values updated, so doesn't need to do anything. This also fixes shared events getting lost over hibernate as this path made them look unregistered. Fixes: da351827240e ("firmware: arm_sdei: Add support for CPU and system power states") Reported-by: Liguang Zhang <zhangliguang@linux.alibaba.com> Signed-off-by: James Morse <james.morse@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
* efi: Add a sanity check to efivar_store_raw()Vladis Dronov2020-03-181-0/+3
| | | | | | | | | | | | | | | | commit d6c066fda90d578aacdf19771a027ed484a79825 upstream. Add a sanity check to efivar_store_raw() the same way efivar_{attr,size,data}_read() and efivar_show_raw() have it. Signed-off-by: Vladis Dronov <vdronov@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200305084041.24053-3-vdronov@redhat.com Link: https://lore.kernel.org/r/20200308080859.21568-25-ardb@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* efi: Fix a race and a buffer overflow while reading efivars via sysfsVladis Dronov2020-03-181-9/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 286d3250c9d6437340203fb64938bea344729a0e upstream. There is a race and a buffer overflow corrupting a kernel memory while reading an EFI variable with a size more than 1024 bytes via the older sysfs method. This happens because accessing struct efi_variable in efivar_{attr,size,data}_read() and friends is not protected from a concurrent access leading to a kernel memory corruption and, at best, to a crash. The race scenario is the following: CPU0: CPU1: efivar_attr_read() var->DataSize = 1024; efivar_entry_get(... &var->DataSize) down_interruptible(&efivars_lock) efivar_attr_read() // same EFI var var->DataSize = 1024; efivar_entry_get(... &var->DataSize) down_interruptible(&efivars_lock) virt_efi_get_variable() // returns EFI_BUFFER_TOO_SMALL but // var->DataSize is set to a real // var size more than 1024 bytes up(&efivars_lock) virt_efi_get_variable() // called with var->DataSize set // to a real var size, returns // successfully and overwrites // a 1024-bytes kernel buffer up(&efivars_lock) This can be reproduced by concurrent reading of an EFI variable which size is more than 1024 bytes: ts# for cpu in $(seq 0 $(nproc --ignore=1)); do ( taskset -c $cpu \ cat /sys/firmware/efi/vars/KEKDefault*/size & ) ; done Fix this by using a local variable for a var's data buffer size so it does not get overwritten. Fixes: e14ab23dde12b80d ("efivars: efivar_entry API") Reported-by: Bob Sanders <bob.sanders@hpe.com> and the LTP testsuite Signed-off-by: Vladis Dronov <vdronov@redhat.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200305084041.24053-2-vdronov@redhat.com Link: https://lore.kernel.org/r/20200308080859.21568-24-ardb@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* efi: READ_ONCE rng seed size before munmapJason A. Donenfeld2020-03-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | commit be36f9e7517e17810ec369626a128d7948942259 upstream. This function is consistent with using size instead of seed->size (except for one place that this patch fixes), but it reads seed->size without using READ_ONCE, which means the compiler might still do something unwanted. So, this commit simply adds the READ_ONCE wrapper. Fixes: 636259880a7e ("efi: Add support for seeding the RNG from a UEFI ...") Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: linux-efi@vger.kernel.org Cc: Ingo Molnar <mingo@kernel.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/20200217123354.21140-1-Jason@zx2c4.com Link: https://lore.kernel.org/r/20200221084849.26878-5-ardb@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* firmware: imx: Align imx_sc_msg_req_cpu_start to 4Leonard Crestez2020-03-121-1/+1
| | | | | | | | | | | | | | | | | commit f5bfeff44612d304deb100065a9f712309dc2783 upstream. The imx SC api strongly assumes that messages are composed out of 4-bytes words but some of our message structs have odd sizeofs. This produces many oopses with CONFIG_KASAN=y. Fix by marking with __aligned(4). Fixes: d90bf296ae18 ("firmware: imx: Add support to start/stop a CPU") Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* firmware: imx: scu-pd: Align imx sc msg structs to 4Leonard Crestez2020-03-121-1/+1
| | | | | | | | | | | | | | | | | commit 7c1a1c814ccc858633c761951c2546041202b24e upstream. The imx SC api strongly assumes that messages are composed out of 4-bytes words but some of our message structs have odd sizeofs. This produces many oopses with CONFIG_KASAN=y. Fix by marking with __aligned(4). Fixes: c800cd7824bd ("firmware: imx: add SCU power domain driver") Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* firmware: imx: misc: Align imx sc msg structs to 4Leonard Crestez2020-03-121-3/+3
| | | | | | | | | | | | | | | | | | | | commit 1e6a4eba693ac72e6f91b4252458c933110e5f4c upstream. The imx SC api strongly assumes that messages are composed out of 4-bytes words but some of our message structs have odd sizeofs. This produces many oopses with CONFIG_KASAN=y: BUG: KASAN: stack-out-of-bounds in imx_mu_send_data+0x108/0x1f0 It shouldn't cause an issues in normal use because these structs are always allocated on the stack. Fixes: 15e1f2bc8b3b ("firmware: imx: add misc svc support") Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-12 14:49:18 +0000