mirror of
https://github.com/torvalds/linux.git
synced 2024-11-23 04:31:50 +00:00
c44b6be62e
When the flash is not owned by the non-secure world, accessing the EFI variables is straight-forward and done via EFI Runtime Variable Services. In this case, critical variables for system integrity and security are normally stored in the dedicated secure storage and can only be manipulated directly from the secure world. Usually, small embedded devices don't have the special dedicated secure storage. The eMMC device with an RPMB partition is becoming more common, and we can use this RPMB partition to store the EFI Variables. The eMMC device is typically owned by the non-secure world (Linux in our case). There is an existing solution utilizing eMMC RPMB partition for EFI Variables, it is implemented by interacting with TEE (OP-TEE in this case), StandaloneMM (as EFI Variable Service Pseudo TA), eMMC driver and tee-supplicant. The last piece is the tee-based variable access driver to interact with TEE and StandaloneMM. So let's add the kernel functions needed. This feature is implemented as a kernel module. StMM PTA has TA_FLAG_DEVICE_ENUM_SUPP flag when registered to OP-TEE so that this tee_stmm_efi module is probed after tee-supplicant starts, since "SetVariable" EFI Runtime Variable Service requires to interact with tee-supplicant. Acked-by: Sumit Garg <sumit.garg@linaro.org> Co-developed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
319 lines
11 KiB
Plaintext
319 lines
11 KiB
Plaintext
# 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.
|