| # SPDX-License-Identifier: GPL-2.0-only |
| menu "EFI (Extensible Firmware Interface) Support" |
| depends on EFI |
| |
| config EFI_ESRT |
| bool |
| depends on EFI |
| default y |
| |
| config EFI_VARS_PSTORE |
| tristate "Register efivars backend for pstore" |
| depends on PSTORE |
| select UCS2_STRING |
| default y |
| help |
| Say Y here to enable use efivars as a backend to pstore. This |
| will allow writing console messages, crash dumps, or anything |
| else supported by pstore to EFI variables. |
| |
| config EFI_VARS_PSTORE_DEFAULT_DISABLE |
| bool "Disable using efivars as a pstore backend by default" |
| depends on EFI_VARS_PSTORE |
| default n |
| help |
| Saying Y here will disable the use of efivars as a storage |
| backend for pstore by default. This setting can be overridden |
| using the efivars module's pstore_disable parameter. |
| |
| config EFI_SOFT_RESERVE |
| bool "Reserve EFI Specific Purpose Memory" |
| depends on EFI && EFI_STUB && ACPI_HMAT |
| default ACPI_HMAT |
| help |
| On systems that have mixed performance classes of memory EFI |
| may indicate specific purpose memory with an attribute (See |
| EFI_MEMORY_SP in UEFI 2.8). A memory range tagged with this |
| attribute may have unique performance characteristics compared |
| to the system's general purpose "System RAM" pool. On the |
| expectation that such memory has application specific usage, |
| and its base EFI memory type is "conventional" answer Y to |
| arrange for the kernel to reserve it as a "Soft Reserved" |
| resource, and set aside for direct-access (device-dax) by |
| default. The memory range can later be optionally assigned to |
| the page allocator by system administrator policy via the |
| device-dax kmem facility. Say N to have the kernel treat this |
| memory as "System RAM" by default. |
| |
| If unsure, say Y. |
| |
| config EFI_DXE_MEM_ATTRIBUTES |
| bool "Adjust memory attributes in EFISTUB" |
| depends on EFI && EFI_STUB && X86 |
| default y |
| help |
| UEFI specification does not guarantee all memory to be |
| accessible for both write and execute as the kernel expects |
| it to be. |
| Use DXE services to check and alter memory protection |
| attributes during boot via EFISTUB to ensure that memory |
| ranges used by the kernel are writable and executable. |
| |
| config EFI_PARAMS_FROM_FDT |
| bool |
| help |
| Select this config option from the architecture Kconfig if |
| the EFI runtime support gets system table address, memory |
| map address, and other parameters from the device tree. |
| |
| config EFI_RUNTIME_WRAPPERS |
| bool |
| |
| config EFI_GENERIC_STUB |
| bool |
| |
| config EFI_ZBOOT |
| bool "Enable the generic EFI decompressor" |
| depends on EFI_GENERIC_STUB && !ARM |
| select HAVE_KERNEL_GZIP |
| select HAVE_KERNEL_LZ4 |
| select HAVE_KERNEL_LZMA |
| select HAVE_KERNEL_LZO |
| select HAVE_KERNEL_XZ |
| select HAVE_KERNEL_ZSTD |
| help |
| Create the bootable image as an EFI application that carries the |
| actual kernel image in compressed form, and decompresses it into |
| memory before executing it via LoadImage/StartImage EFI boot service |
| calls. For compatibility with non-EFI loaders, the payload can be |
| decompressed and executed by the loader as well, provided that the |
| loader implements the decompression algorithm and that non-EFI boot |
| is supported by the encapsulated image. (The compression algorithm |
| used is described in the zboot image header) |
| |
| config EFI_ARMSTUB_DTB_LOADER |
| bool "Enable the DTB loader" |
| depends on EFI_GENERIC_STUB && !RISCV && !LOONGARCH |
| default y |
| help |
| Select this config option to add support for the dtb= command |
| line parameter, allowing a device tree blob to be loaded into |
| memory from the EFI System Partition by the stub. |
| |
| If the device tree is provided by the platform or by |
| the bootloader this option may not be needed. |
| But, for various development reasons and to maintain existing |
| functionality for bootloaders that do not have such support |
| this option is necessary. |
| |
| config EFI_BOOTLOADER_CONTROL |
| tristate "EFI Bootloader Control" |
| select UCS2_STRING |
| default n |
| help |
| This module installs a reboot hook, such that if reboot() is |
| invoked with a string argument NNN, "NNN" is copied to the |
| "LoaderEntryOneShot" EFI variable, to be read by the |
| bootloader. If the string matches one of the boot labels |
| defined in its configuration, the bootloader will boot once |
| to that label. The "LoaderEntryRebootReason" EFI variable is |
| set with the reboot reason: "reboot" or "shutdown". The |
| bootloader reads this reboot reason and takes particular |
| action according to its policy. |
| |
| config EFI_CAPSULE_LOADER |
| tristate "EFI capsule loader" |
| depends on EFI |
| help |
| This option exposes a loader interface "/dev/efi_capsule_loader" for |
| users to load EFI capsules. This driver requires working runtime |
| capsule support in the firmware, which many OEMs do not provide. |
| |
| Most users should say N. |
| |
| config EFI_CAPSULE_QUIRK_QUARK_CSH |
| bool "Add support for Quark capsules with non-standard headers" |
| depends on X86 && !64BIT |
| select EFI_CAPSULE_LOADER |
| default y |
| help |
| Add support for processing Quark X1000 EFI capsules, whose header |
| layout deviates from the layout mandated by the UEFI specification. |
| |
| config EFI_TEST |
| tristate "EFI Runtime Service Tests Support" |
| depends on EFI |
| default n |
| help |
| This driver uses the efi.<service> function pointers directly instead |
| of going through the efivar API, because it is not trying to test the |
| kernel subsystem, just for testing the UEFI runtime service |
| interfaces which are provided by the firmware. This driver is used |
| by the Firmware Test Suite (FWTS) for testing the UEFI runtime |
| interfaces readiness of the firmware. |
| Details for FWTS are available from: |
| <https://wiki.ubuntu.com/FirmwareTestSuite> |
| |
| Say Y here to enable the runtime services support via /dev/efi_test. |
| If unsure, say N. |
| |
| config EFI_DEV_PATH_PARSER |
| bool |
| |
| config APPLE_PROPERTIES |
| bool "Apple Device Properties" |
| depends on EFI_STUB && X86 |
| select EFI_DEV_PATH_PARSER |
| select UCS2_STRING |
| help |
| Retrieve properties from EFI on Apple Macs and assign them to |
| devices, allowing for improved support of Apple hardware. |
| Properties that would otherwise be missing include the |
| Thunderbolt Device ROM and GPU configuration data. |
| |
| If unsure, say Y if you have a Mac. Otherwise N. |
| |
| config RESET_ATTACK_MITIGATION |
| bool "Reset memory attack mitigation" |
| depends on EFI_STUB |
| help |
| Request that the firmware clear the contents of RAM after a reboot |
| using the TCG Platform Reset Attack Mitigation specification. This |
| protects against an attacker forcibly rebooting the system while it |
| still contains secrets in RAM, booting another OS and extracting the |
| secrets. This should only be enabled when userland is configured to |
| clear the MemoryOverwriteRequest flag on clean shutdown after secrets |
| have been evicted, since otherwise it will trigger even on clean |
| reboots. |
| |
| config EFI_RCI2_TABLE |
| bool "EFI Runtime Configuration Interface Table Version 2 Support" |
| depends on X86 || COMPILE_TEST |
| help |
| Displays the content of the Runtime Configuration Interface |
| Table version 2 on Dell EMC PowerEdge systems as a binary |
| attribute 'rci2' under /sys/firmware/efi/tables directory. |
| |
| RCI2 table contains BIOS HII in XML format and is used to populate |
| BIOS setup page in Dell EMC OpenManage Server Administrator tool. |
| The BIOS setup page contains BIOS tokens which can be configured. |
| |
| Say Y here for Dell EMC PowerEdge systems. |
| |
| config EFI_DISABLE_PCI_DMA |
| bool "Clear Busmaster bit on PCI bridges during ExitBootServices()" |
| help |
| Disable the busmaster bit in the control register on all PCI bridges |
| while calling ExitBootServices() and passing control to the runtime |
| kernel. System firmware may configure the IOMMU to prevent malicious |
| PCI devices from being able to attack the OS via DMA. However, since |
| firmware can't guarantee that the OS is IOMMU-aware, it will tear |
| down IOMMU configuration when ExitBootServices() is called. This |
| leaves a window between where a hostile device could still cause |
| damage before Linux configures the IOMMU again. |
| |
| If you say Y here, the EFI stub will clear the busmaster bit on all |
| PCI bridges before ExitBootServices() is called. This will prevent |
| any malicious PCI devices from being able to perform DMA until the |
| kernel reenables busmastering after configuring the IOMMU. |
| |
| This option will cause failures with some poorly behaved hardware |
| and should not be enabled without testing. The kernel commandline |
| options "efi=disable_early_pci_dma" or "efi=no_disable_early_pci_dma" |
| may be used to override this option. |
| |
| config EFI_EARLYCON |
| def_bool y |
| depends on SERIAL_EARLYCON && !ARM |
| select FONT_SUPPORT |
| select ARCH_USE_MEMREMAP_PROT |
| |
| config EFI_CUSTOM_SSDT_OVERLAYS |
| bool "Load custom ACPI SSDT overlay from an EFI variable" |
| depends on ACPI |
| default ACPI_TABLE_UPGRADE |
| help |
| Allow loading of an ACPI SSDT overlay from an EFI variable specified |
| by a kernel command line option. |
| |
| See Documentation/admin-guide/acpi/ssdt-overlays.rst for more |
| information. |
| |
| config EFI_DISABLE_RUNTIME |
| bool "Disable EFI runtime services support by default" |
| default y if PREEMPT_RT |
| help |
| Allow to disable the EFI runtime services support by default. This can |
| already be achieved by using the efi=noruntime option, but it could be |
| useful to have this default without any kernel command line parameter. |
| |
| The EFI runtime services are disabled by default when PREEMPT_RT is |
| enabled, because measurements have shown that some EFI functions calls |
| might take too much time to complete, causing large latencies which is |
| an issue for Real-Time kernels. |
| |
| This default can be overridden by using the efi=runtime option. |
| |
| config EFI_COCO_SECRET |
| bool "EFI Confidential Computing Secret Area Support" |
| help |
| Confidential Computing platforms (such as AMD SEV) allow the |
| Guest Owner to securely inject secrets during guest VM launch. |
| The secrets are placed in a designated EFI reserved memory area. |
| |
| In order to use the secrets in the kernel, the location of the secret |
| area (as published in the EFI config table) must be kept. |
| |
| If you say Y here, the address of the EFI secret area will be kept |
| for usage inside the kernel. This will allow the |
| virt/coco/efi_secret module to access the secrets, which in turn |
| allows userspace programs to access the injected secrets. |
| |
| config UNACCEPTED_MEMORY |
| bool |
| depends on EFI_STUB |
| help |
| Some Virtual Machine platforms, such as Intel TDX, require |
| some memory to be "accepted" by the guest before it can be used. |
| This mechanism helps prevent malicious hosts from making changes |
| to guest memory. |
| |
| UEFI specification v2.9 introduced EFI_UNACCEPTED_MEMORY memory type. |
| |
| This option adds support for unaccepted memory and makes such memory |
| usable by the kernel. |
| |
| config EFI_EMBEDDED_FIRMWARE |
| bool |
| select CRYPTO_LIB_SHA256 |
| |
| endmenu |
| |
| config UEFI_CPER |
| bool |
| |
| config UEFI_CPER_ARM |
| bool |
| depends on UEFI_CPER && ( ARM || ARM64 ) |
| default y |
| |
| config UEFI_CPER_X86 |
| bool |
| depends on UEFI_CPER && X86 |
| default y |
| |
| config TEE_STMM_EFI |
| tristate "TEE-based EFI runtime variable service driver" |
| depends on EFI && OPTEE |
| help |
| Select this config option if TEE is compiled to include StandAloneMM |
| as a separate secure partition. It has the ability to check and store |
| EFI variables on an RPMB or any other non-volatile medium used by |
| StandAloneMM. |
| |
| Enabling this will change the EFI runtime services from the firmware |
| provided functions to TEE calls. |
| |
| To compile this driver as a module, choose M here: the module |
| will be called tee_stmm_efi. |
