kernel.git/drivers/firmware/efi/runtime-wrappers.c, branch linux-4.9.y

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

2021-10-27T07:33:57Z

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

x86/platform/UV: Use efi_runtime_lock to serialise BIOS calls

2019-02-20T09:18:33Z

commit f331e766c4be33f4338574f3c9f7f77e98ab4571 upstream. Calls into UV firmware must be protected against concurrency, expose the efi_runtime_lock to the UV platform, and use it to serialise UV BIOS calls. Signed-off-by: Hedi Berriche Signed-off-by: Borislav Petkov Reviewed-by: Ard Biesheuvel Reviewed-by: Russ Anderson Reviewed-by: Dimitri Sivanich Reviewed-by: Mike Travis Cc: Andy Shevchenko Cc: Bhupesh Sharma Cc: Darren Hart Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: linux-efi Cc: platform-driver-x86@vger.kernel.org Cc: stable@vger.kernel.org # v4.9+ Cc: Steve Wahl Cc: Thomas Gleixner Cc: x86-ml Link: https://lkml.kernel.org/r/20190213193413.25560-5-hedi.berriche@hpe.com Signed-off-by: Greg Kroah-Hartman

efi: Replace runtime services spinlock with semaphore

2016-09-09T15:08:43Z

The purpose of the efi_runtime_lock is to prevent concurrent calls into the firmware. There is no need to use spinlocks here, as long as we ensure that runtime service invocations from an atomic context (i.e., EFI pstore) cannot block. So use a semaphore instead, and use down_trylock() in the nonblocking case. We don't use a mutex here because the mutex_trylock() function must not be called from interrupt context, whereas the down_trylock() can. Signed-off-by: Ard Biesheuvel Cc: Leif Lindholm Cc: Mark Rutland Cc: Sylvain Chouleur Signed-off-by: Matt Fleming

efi: Convert efi_call_virt() to efi_call_virt_pointer()

2016-06-27T11:06:56Z

This commit makes a few slight modifications to the efi_call_virt() macro to get it to work with function pointers that are stored in locations other than efi.systab->runtime, and renames the macro to efi_call_virt_pointer(). The majority of the changes here are to pull these macros up into header files so that they can be accessed from outside of drivers/firmware/efi/runtime-wrappers.c. The most significant change not directly related to the code move is to add an extra "p" argument into the appropriate efi_call macros, and use that new argument in place of the, formerly hard-coded, efi.systab->runtime pointer. The last piece of the puzzle was to add an efi_call_virt() macro back into drivers/firmware/efi/runtime-wrappers.c to wrap around the new efi_call_virt_pointer() macro - this was mainly to keep the code from looking too cluttered by adding a bunch of extra references to efi.systab->runtime everywhere. Note that I also broke up the code in the efi_call_virt_pointer() macro a bit in the process of moving it. Signed-off-by: Alex Thorlton Signed-off-by: Matt Fleming Cc: Ard Biesheuvel Cc: Catalin Marinas Cc: Dimitri Sivanich Cc: Linus Torvalds Cc: Mark Rutland Cc: Peter Zijlstra Cc: Roy Franz Cc: Russ Anderson Cc: Russell King Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-arm-kernel@lists.infradead.org Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1466839230-12781-5-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar

efi/runtime-wrappers: Remove ARCH_EFI_IRQ_FLAGS_MASK #ifdef

2016-04-28T09:34:13Z

Now that arm, arm64, and x86 all provide ARCH_EFI_IRQ_FLAGS_MASK, we can get rid of the trivial and now unused implementation of efi_call_virt_check_flags(). Signed-off-by: Mark Rutland Signed-off-by: Matt Fleming Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: Catalin Marinas Cc: Leif Lindholm Cc: Peter Zijlstra Cc: Russell King Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1461614832-17633-41-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar

efi/runtime-wrappers: Detect firmware IRQ flag corruption

2016-04-28T09:34:11Z

The UEFI spec allows runtime services to be called with interrupts masked or unmasked, and if a runtime service function needs to mask interrupts, it must restore the mask to its original state before returning (i.e. from the PoV of the OS, this does not change across a call). Firmware should never unmask exceptions, as these may then be taken by the OS unexpectedly. Unfortunately, some firmware has been seen to unmask IRQs (and potentially other maskable exceptions) across runtime services calls, leaving IRQ flags corrupted after returning from a runtime services function call. This may be detected by the IRQ tracing code, but often goes unnoticed, leaving a potentially disastrous bug hidden. This patch detects when the IRQ flags are corrupted by an EFI runtime services call, logging the call and specific corruption to the console. While restoring the expected value of the flags is insufficient to avoid problems, we do so to avoid redundant warnings from elsewhere (e.g. IRQ tracing). The set of bits in flags which we want to check is architecture-specific (e.g. we want to check FIQ on arm64, but not the zero flag on x86), so each arch must provide ARCH_EFI_IRQ_FLAGS_MASK to describe those. In the absence of this mask, the check is a no-op, and we redundantly save the flags twice, but that will be short-lived as subsequent patches will implement this and remove the scaffolding. Signed-off-by: Mark Rutland Signed-off-by: Matt Fleming Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: Catalin Marinas Cc: Leif Lindholm Cc: Peter Zijlstra Cc: Robin Murphy Cc: Russell King Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1461614832-17633-37-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar

efi/runtime-wrappers: Remove redundant #ifdefs

2016-04-28T09:34:10Z

Now that all users of the EFI runtime wrappers (arm,arm64,x86) have been migrated to the new setup/teardown macros, we don't need to support overridden {__,}efi_call_virt() implementations. This patch removes the unnecessary #ifdefs. Signed-off-by: Mark Rutland Signed-off-by: Matt Fleming Cc: Ard Biesheuvel Cc: Borislav Petkov Cc: Catalin Marinas Cc: Leif Lindholm Cc: Peter Zijlstra Cc: Russell King Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1461614832-17633-36-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar

efi/runtime-wrappers: Add {__,}efi_call_virt() templates

2016-04-28T09:34:06Z

Currently each architecture must implement two macros, efi_call_virt() and __efi_call_virt(), which only differ by the presence or absence of a return type. Otherwise, the logic surrounding the call is identical. As each architecture must define the entire body of each, we can't place any generic manipulation (e.g. irq flag validation) in the middle. This patch adds template implementations of these macros. With these, arch code can implement three template macros, avoiding reptition for the void/non-void return cases: * arch_efi_call_virt_setup() Sets up the environment for the call (e.g. switching page tables, allowing kernel-mode use of floating point, if required). * arch_efi_call_virt() Performs the call. The last expression in the macro must be the call itself, allowing the logic to be shared by the void and non-void cases. * arch_efi_call_virt_teardown() Restores the usual kernel environment once the call has returned. While the savings from repition are minimal, we additionally gain the ability to add common code around the call with the call environment set up. This can be used to detect common firmware issues (e.g. bad irq mask management). Signed-off-by: Mark Rutland Signed-off-by: Matt Fleming Reviewed-by: Ard Biesheuvel Cc: Borislav Petkov Cc: Catalin Marinas Cc: Leif Lindholm Cc: Peter Zijlstra Cc: Russell King Cc: Thomas Gleixner Cc: Will Deacon Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1461614832-17633-32-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar

efi/runtime-wrappers: Run UEFI Runtime Services with interrupts enabled

2016-02-22T07:26:25Z

The UEFI spec allows Runtime Services to be invoked with interrupts enabled. The only reason we were disabling interrupts was to prevent recursive calls into the services on the same CPU, which will lead to deadlock. However, the only context where such invocations may occur legally is from efi-pstore via efivars, and that code has been updated to call a non-blocking alternative when invoked from a non-interruptible context. So instead, update the ordinary, blocking UEFI Runtime Services wrappers to execute with interrupts enabled. This aims to prevent excessive interrupt latencies on uniprocessor platforms with slow variable stores. Note that other OSes such as Windows call UEFI Runtime Services with interrupts enabled as well. Signed-off-by: Ard Biesheuvel Signed-off-by: Matt Fleming Cc: Andy Lutomirski Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Sai Praneeth Prakhya Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1455712566-16727-3-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar

efi: Runtime-wrapper: Get rid of the rtc_lock spinlock

2016-02-03T10:31:05Z

The rtc_lock spinlock aims to serialize access to the CMOS RTC between the UEFI firmware and the kernel drivers that use it directly. However, x86 is the only arch that performs such direct accesses, and that never uses the time related UEFI runtime services. Since no other UEFI enlightened architectures have a legcay CMOS RTC anyway, we can remove the rtc_lock spinlock entirely. Signed-off-by: Ard Biesheuvel Signed-off-by: Matt Fleming Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/1454364428-494-7-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar