kernel/drivers/firmware/google/gsmi.c, branch linux-6.5.y

Merge tag 'efi-next-for-v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi

2023-02-23T22:41:48Z

Pull EFI updates from Ard Biesheuvel: "A healthy mix of EFI contributions this time: - Performance tweaks for efifb earlycon (Andy) - Preparatory refactoring and cleanup work in the efivar layer, which is needed to accommodate the Snapdragon arm64 laptops that expose their EFI variable store via a TEE secure world API (Johan) - Enhancements to the EFI memory map handling so that Xen dom0 can safely access EFI configuration tables (Demi Marie) - Wire up the newly introduced IBT/BTI flag in the EFI memory attributes table, so that firmware that is generated with ENDBR/BTI landing pads will be mapped with enforcement enabled - Clean up how we check and print the EFI revision exposed by the firmware - Incorporate EFI memory attributes protocol definition and wire it up in the EFI zboot code (Evgeniy) This ensures that these images can execute under new and stricter rules regarding the default memory permissions for EFI page allocations (More work is in progress here) - CPER header cleanup (Dan Williams) - Use a raw spinlock to protect the EFI runtime services stack on arm64 to ensure the correct semantics under -rt (Pierre) - EFI framebuffer quirk for Lenovo Ideapad (Darrell)" * tag 'efi-next-for-v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: (24 commits) firmware/efi sysfb_efi: Add quirk for Lenovo IdeaPad Duet 3 arm64: efi: Make efi_rt_lock a raw_spinlock efi: Add mixed-mode thunk recipe for GetMemoryAttributes efi: x86: Wire up IBT annotation in memory attributes table efi: arm64: Wire up BTI annotation in memory attributes table efi: Discover BTI support in runtime services regions efi/cper, cxl: Remove cxl_err.h efi: Use standard format for printing the EFI revision efi: Drop minimum EFI version check at boot efi: zboot: Use EFI protocol to remap code/data with the right attributes efi/libstub: Add memory attribute protocol definitions efi: efivars: prevent double registration efi: verify that variable services are supported efivarfs: always register filesystem efi: efivars: add efivars printk prefix efi: Warn if trying to reserve memory under Xen efi: Actually enable the ESRT under Xen efi: Apply allowlist to EFI configuration tables when running under Xen efi: xen: Implement memory descriptor lookup based on hypercall efi: memmap: Disregard bogus entries instead of returning them ...

gsmi: fix null-deref in gsmi_get_variable

2023-01-20T12:23:42Z

We can get EFI variables without fetching the attribute, so we must allow for that in gsmi. commit 859748255b43 ("efi: pstore: Omit efivars caching EFI varstore access layer") added a new get_variable call with attr=NULL, which triggers panic in gsmi. Fixes: 74c5b31c6618 ("driver: Google EFI SMI") Cc: stable Signed-off-by: Khazhismel Kumykov Link: https://lore.kernel.org/r/20230118010212.1268474-1-khazhy@google.com Signed-off-by: Greg Kroah-Hartman

efi: efivars: drop kobject from efivars_register()

2023-01-17T15:14:36Z

Since commit 0f5b2c69a4cb ("efi: vars: Remove deprecated 'efivars' sysfs interface") and the removal of the sysfs interface there are no users of the efivars kobject. Drop the kobject argument from efivars_register() and add a new efivar_is_available() helper in favour of the old efivars_kobject(). Note that the new helper uses the prefix 'efivar' (i.e. without an 's') for consistency with efivar_supports_writes() and the rest of the interface (except the registration functions). For the benefit of drivers with optional EFI support, also provide a dummy implementation of efivar_is_available(). Signed-off-by: Johan Hovold Signed-off-by: Ard Biesheuvel

firmware: google: Test spinlock on panic path to avoid lockups

2022-09-24T12:59:44Z

Currently the gsmi driver registers a panic notifier as well as reboot and die notifiers. The callbacks registered are called in atomic and very limited context - for instance, panic disables preemption and local IRQs, also all secondary CPUs (not executing the panic path) are shutdown. With that said, taking a spinlock in this scenario is a dangerous invitation for lockup scenarios. So, fix that by checking if the spinlock is free to acquire in the panic notifier callback - if not, bail-out and avoid a potential hang. Fixes: 74c5b31c6618 ("driver: Google EFI SMI") Cc: Andrew Morton Cc: Ard Biesheuvel Cc: David Gow Cc: Greg Kroah-Hartman Cc: Julius Werner Cc: Petr Mladek Reviewed-by: Evan Green Signed-off-by: Guilherme G. Piccoli Link: https://lore.kernel.org/r/20220909200755.189679-1-gpiccoli@igalia.com Signed-off-by: Greg Kroah-Hartman

kernel.h: split out panic and oops helpers

2021-07-01T18:06:04Z

kernel.h is being used as a dump for all kinds of stuff for a long time. Here is the attempt to start cleaning it up by splitting out panic and oops helpers. There are several purposes of doing this: - dropping dependency in bug.h - dropping a loop by moving out panic_notifier.h - unload kernel.h from something which has its own domain At the same time convert users tree-wide to use new headers, although for the time being include new header back to kernel.h to avoid twisted indirected includes for existing users. [akpm@linux-foundation.org: thread_info.h needs limits.h] [andriy.shevchenko@linux.intel.com: ia64 fix] Link: https://lkml.kernel.org/r/20210520130557.55277-1-andriy.shevchenko@linux.intel.com Link: https://lkml.kernel.org/r/20210511074137.33666-1-andriy.shevchenko@linux.intel.com Signed-off-by: Andy Shevchenko Reviewed-by: Bjorn Andersson Co-developed-by: Andrew Morton Acked-by: Mike Rapoport Acked-by: Corey Minyard Acked-by: Christian Brauner Acked-by: Arnd Bergmann Acked-by: Kees Cook Acked-by: Wei Liu Acked-by: Rasmus Villemoes Signed-off-by: Andrew Morton Acked-by: Sebastian Reichel Acked-by: Luis Chamberlain Acked-by: Stephen Boyd Acked-by: Thomas Bogendoerfer Acked-by: Helge Deller # parisc Signed-off-by: Linus Torvalds

firmware: google: Enable s0ix logging by default

2021-04-02T14:30:21Z

Many moons ago, support was added to the SMI handlers to log s0ix entry and exit. Early iterations of firmware on Apollo Lake correctly returned "unsupported" for this new command they did not recognize, but unfortunately also contained a quirk where this command would cause them to power down rather than resume from s0ix. Fixes for this quirk were pushed out long ago, so all APL devices still in the field should have updated firmware. As such, we no longer need to have the s0ix_logging_enable be opt-in, where every new platform has to add this to their kernel commandline parameters. Change it to be on by default. In theory we could remove the parameter altogether: updated versions of Chrome OS containing a kernel with this change would also be coupled with firmware that behaves properly with these commands. Eventually we should probably do that. For now, convert this to an opt-out parameter so there's an emergency valve for people who are deliberately running old firmware, or as an escape hatch in case of unforeseen regressions. Signed-off-by: Evan Green Link: https://lore.kernel.org/r/20210401140430.1.Ie141e6044d9b0d5aba72cb08857fdb43660c54d3@changeid Signed-off-by: Greg Kroah-Hartman

firmware: gsmi: Drop the use of dma_pool_* API functions

2020-11-09T17:48:06Z

GSMI driver uses dma_pool_* API functions for buffer allocation because it requires that the SMI buffers are allocated within 32-bit physical address space. However, this does not work well with IOMMU since there is no real device and hence no domain associated with the device. Since this is not a real device, it does not require any device address(IOVA) for the buffer allocations. The only requirement is to ensure that the physical address allocated to the buffer is within 32-bit physical address space. This is because the buffers have nothing to do with DMA at all. It is required for communication with firmware executing in SMI mode which has access only to the bottom 4GiB of memory. Hence, this change switches to using a SLAB cache created with SLAB_CACHE_DMA32 that guarantees that the allocation happens from the DMA32 memory zone. All calls to dma_pool_* are replaced with kmem_cache_*. In addition to that, all the code for managing the dma_pool for GSMI platform device is dropped. Signed-off-by: Furquan Shaikh Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20201022071550.1192947-1-furquan@google.com Signed-off-by: Greg Kroah-Hartman

efi: gsmi: fix false dependency on CONFIG_EFI_VARS

2020-09-29T17:40:57Z

The gsmi code does not actually rely on CONFIG_EFI_VARS, since it only uses the efivars abstraction that is included unconditionally when CONFIG_EFI is defined. CONFIG_EFI_VARS controls the inclusion of the code that exposes the sysfs entries, and which has been deprecated for some time. Signed-off-by: Ard Biesheuvel

firmware: google: Probe for a GSMI handler in firmware

2020-01-14T20:46:48Z

Currently this driver is loaded if the DMI string matches coreboot and has a proper smi_command in the ACPI FADT table, but a GSMI handler in SMM is an optional feature in coreboot. So probe for a SMM GSMI handler before initializing the driver. If the smihandler leaves the calling argument in %eax in the SMM save state untouched that generally means the is no handler for GSMI. Signed-off-by: Arthur Heymans Signed-off-by: Patrick Rudolph Link: https://lore.kernel.org/r/20191118101934.22526-4-patrick.rudolph@9elements.com Signed-off-by: Greg Kroah-Hartman

firmware: google: Unregister driver_info on failure and exit in gsmi

2020-01-14T20:46:48Z

Fix a bug where the kernel module couldn't be loaded after unloading, as the platform driver wasn't released on exit. Signed-off-by: Arthur Heymans Signed-off-by: Patrick Rudolph Link: https://lore.kernel.org/r/20191118101934.22526-3-patrick.rudolph@9elements.com Signed-off-by: Greg Kroah-Hartman