Mirrors/u-boot
2
0
Fork 0
mirror of https://github.com/AsahiLinux/u-boot synced 2024-12-25 12:33:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
u-boot/lib/efi_loader/Kconfig

351 lines
10 KiB
Text
Raw Normal View History

efi_loader: hook up in build environment Now that we have all the bits and pieces ready for EFI payload loading support, hook them up in Makefiles and KConfigs so that we can build. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> [trini: Enable only when we of OF_LIBFDT, disable on kwb and colibri_pxa270] Signed-off-by: Tom Rini <trini@konsulko.com>
2016-03-04 00:10:07 +00:00
config EFI_LOADER
efi_loader: reword the EFI_LOADER config option No need to mention U-Boot in brief description. Fix several typos, mention iPXE. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-11 08:27:58 +00:00
bool "Support running UEFI applications"
efi_loader: restrict EFI_LOADER to armv7 and armv8 on ARM fatload USB was reported to fail on the Sheevaplug. Debugging showed that this was caused by an incorrect unaligned write to memory in path_to_uefi(). UEFI on ARM requires that unaligned memory access is enabled. * ARMv5 does not support unaligned access at all. * ARMv6 supports unaligned access when we clear the A flag and set the U flag. * On ARMv7 unaligned access is possible when clearing the aligned flag, which we do in function allow_unaligned() (arch/arm/cpu/armv7/sctlr.S). For none of the other cpus in arch/arm/cpu/ we have implemented a similar function. * ARMv8 allows unaligned access. Let EFI_LOADER on ARM depend on SYS_CPU=armv7 or SYS_CPU=armv8. Once we have implemented allow_unaligned() for other ARM CPUs we can add these to Kconfig. Reported-by: Gray Remlin <gryrmln@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-11-17 09:44:16 +00:00
depends on OF_LIBFDT && ( \
efi_loader: enable EFI_LOADER on arm1136 and arm1176 With an implementation for allow_unaligned() available for arm1136 and arm1176 UEFI can be supported on these architectures. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-11-19 03:19:09 +00:00
ARM && (SYS_CPU = arm1136 || \
SYS_CPU = arm1176 || \
SYS_CPU = armv7 || \
SYS_CPU = armv8) || \
efi_loader: restrict EFI_LOADER to armv7 and armv8 on ARM fatload USB was reported to fail on the Sheevaplug. Debugging showed that this was caused by an incorrect unaligned write to memory in path_to_uefi(). UEFI on ARM requires that unaligned memory access is enabled. * ARMv5 does not support unaligned access at all. * ARMv6 supports unaligned access when we clear the A flag and set the U flag. * On ARMv7 unaligned access is possible when clearing the aligned flag, which we do in function allow_unaligned() (arch/arm/cpu/armv7/sctlr.S). For none of the other cpus in arch/arm/cpu/ we have implemented a similar function. * ARMv8 allows unaligned access. Let EFI_LOADER on ARM depend on SYS_CPU=armv7 or SYS_CPU=armv8. Once we have implemented allow_unaligned() for other ARM CPUs we can add these to Kconfig. Reported-by: Gray Remlin <gryrmln@gmail.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-11-17 09:44:16 +00:00
X86 || RISCV || SANDBOX)
efi: Conflict efi_loader with different stub bitness We have 2 users of the EFI headers: efi_loader and the EFI stub. Efi_loader always expects that the bitness of the definitions it uses is identical to the execution. The EFI stub however allows to run x86_64 U-Boot on 32bit EFI and the other way around, so it allows for different bitness of EFI definitions and U-Boot environment. This patch explicitly requests via Kconfig that efi_loader can only be enabled if the bitness is identical. Because we can run efi_loader on x86_64 without EFI stub enabled, it also ensures that this case propagates the correct ABI constraints. Signed-off-by: Alexander Graf <agraf@suse.de>
2018-01-24 13:54:21 +00:00
# We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB
depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT
# We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT
efi_loader: default EFI_LOADER=n on ARM11 Some of the ARM11 boards have tight limits on the size of U-Boots. Hence use EFI_LOADER=n as default on ARM11. Set EFI_LOADER=y for the Raspberry Pi and Raspberry Pi Zero as these boards have sufficient storage on the SD card. Suggested-by: Tom Rini <trini@konsulko.com> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-11-20 17:48:02 +00:00
default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8
Convert LIB_UUID to Kconfig config_fallback.h has some logic that checks a variety of options and selects LIB_UUID if it hasn't already been selected. This will all LIB_UUID in Kconfig and select this option for the list of options to allow us to remove the logic from fallbacks Signed-off-by: Adam Ford <aford173@gmail.com>
2018-02-06 18:14:28 +00:00
select LIB_UUID
Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to Kconfig allows us to drastically shrink the logic in config_fallbacks.h Signed-off-by: Adam Ford <aford173@gmail.com> [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE] Signed-off-by: Tom Rini <trini@konsulko.com>
2018-02-06 18:43:56 +00:00
select HAVE_BLOCK_DEVICE
efi_loader: GetNextVariableName() relies on REGEX Our implementation of GetNextVariableName() relies on CONFIG_REGEX=y. So EFI_LOADER has to select it. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2019-01-22 20:35:23 +00:00
select REGEX
efi_loader: if EFI_LOADER is enabled, enable CFB_CONSOLE_ANSI EFI applications like GRUB issue ANSI sequences for setting colors and for positioning. So if the EFI subsystem is enabled, we should also enable ANSI control sequences by default. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-04-29 21:37:12 +00:00
imply CFB_CONSOLE_ANSI
efi_loader: imply FAT, FAT_WRITE The UEFI spec requires support for the FAT file system. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-03-21 19:45:50 +00:00
imply FAT
imply FAT_WRITE
efi_loader: imply USB_KEYBOARD_FN_KEYS UEFI applications like GRUB and SCT assume that function keys are enabled on the keyboard. Let EFI_LOADER imply USB_KEYBOARD_FN_KEYS. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-12-04 21:58:58 +00:00
imply USB_KEYBOARD_FN_KEYS
efi_loader: imply VIDEO_ANSI UEFI programs like GRUB make change terminal colors which requires support for ANSI escape sequences. Let CONFIG_EFI_LOADER=y imply CONFIG_VIDEO_ANSI. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-01-14 23:49:35 +00:00
imply VIDEO_ANSI
efi_loader: hook up in build environment Now that we have all the bits and pieces ready for EFI payload loading support, hook them up in Makefiles and KConfigs so that we can build. Signed-off-by: Alexander Graf <agraf@suse.de> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> [trini: Enable only when we of OF_LIBFDT, disable on kwb and colibri_pxa270] Signed-off-by: Tom Rini <trini@konsulko.com>
2016-03-04 00:10:07 +00:00
help
efi_loader: reword the EFI_LOADER config option No need to mention U-Boot in brief description. Fix several typos, mention iPXE. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-11 08:27:58 +00:00
Select this option if you want to run UEFI applications (like GNU
GRUB or iPXE) on top of U-Boot. If this option is enabled, U-Boot
will expose the UEFI API to a loaded application, enabling it to
reuse U-Boot's device drivers.
efi_loader: Add bounce buffer support Some hardware that is supported by U-Boot can not handle DMA above 32bits. For these systems, we need to come up with a way to expose the disk interface in a safe way. This patch implements EFI specific bounce buffers. For non-EFI cases, this apparently was no issue so far, since we can just define our environment variables conveniently. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-05-11 16:25:48 +00:00
efi_loader: format Kconfig Use if/endif for dependencies to give structure to the configuration menu. Sort important settings to the top. Abbreviate the short description of EFI_LOADER_HII. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-08 21:17:38 +00:00
if EFI_LOADER
efi_loader: make the UEFI boot manager configurable Some boards are very tight on the binary size. Booting via UEFI is possible without using the boot manager. Provide a configuration option to make the boot manager available. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-01-15 18:02:50 +00:00
config CMD_BOOTEFI_BOOTMGR
bool "UEFI Boot Manager"
default y
help
Select this option if you want to select the UEFI binary to be booted
via UEFI variables Boot####, BootOrder, and BootNext. This enables the
'bootefi bootmgr' command.
efi_loader: add option to initialise EFI subsystem early If this option, CONFIG_EFI_SETUP_EARLY, is enabled, the initialisation of UEFI subsystem will be done as part of U-Boot initialisation. Please note that this option won't be enabled explicitly by users, instead, should be enabled implicitly by other configuration options. Specifically, this feature will be utilised in implementing capsule-on-disk feature. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-10-29 04:47:45 +00:00
config EFI_SETUP_EARLY
bool
default n
efi_loader: configuration of variables store The file based and the OP-TEE based UEFI variable store are mutually exclusive. Define them as choice options in Kconfig. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-07-14 17:18:33 +00:00
choice
prompt "Store for non-volatile UEFI variables"
default EFI_VARIABLE_FILE_STORE
help
Select where non-volatile UEFI variables shall be stored.
efi_loader: UEFI variable persistence Persist non-volatile UEFI variables in a file on the EFI system partition. The file is written whenever a non-volatile UEFI variable is changed after initialization of the UEFI sub-system. The file is read during the UEFI sub-system initialization to restore non-volatile UEFI variables. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-03-19 18:21:58 +00:00
config EFI_VARIABLE_FILE_STORE
bool "Store non-volatile UEFI variables as file"
depends on FAT_WRITE
help
efi_loader: configuration of variables store The file based and the OP-TEE based UEFI variable store are mutually exclusive. Define them as choice options in Kconfig. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-07-14 17:18:33 +00:00
Select this option if you want non-volatile UEFI variables to be
stored as file /ubootefi.var on the EFI system partition.
config EFI_MM_COMM_TEE
bool "UEFI variables storage service via OP-TEE"
depends on OPTEE
help
If OP-TEE is present and running StandAloneMM, dispatch all UEFI
variable related operations to that. The application will verify,
authenticate and store the variables on an RPMB.
endchoice
efi_loader: UEFI variable persistence Persist non-volatile UEFI variables in a file on the EFI system partition. The file is written whenever a non-volatile UEFI variable is changed after initialization of the UEFI sub-system. The file is read during the UEFI sub-system initialization to restore non-volatile UEFI variables. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-03-19 18:21:58 +00:00
efi_loader: pre-seed UEFI variables Include a file with the initial values for non-volatile UEFI variables into the U-Boot binary. If this variable is set, changes to variable PK will not be allowed. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-07-14 19:25:28 +00:00
config EFI_VARIABLES_PRESEED
bool "Initial values for UEFI variables"
depends on EFI_VARIABLE_FILE_STORE
help
Include a file with the initial values for non-volatile UEFI variables
into the U-Boot binary. If this configuration option is set, changes
to authentication related variables (PK, KEK, db, dbx) are not
allowed.
if EFI_VARIABLES_PRESEED
config EFI_VAR_SEED_FILE
string "File with initial values of non-volatile UEFI variables"
default ubootefi.var
help
File with initial values of non-volatile UEFI variables. The file must
be in the same format as the storage in the EFI system partition. The
easiest way to create it is by setting the non-volatile variables in
U-Boot. If a relative file path is used, it is relative to the source
directory.
endif
efi_loader: make variable store size customizable Currently the size of the buffer to keep UEFI variables in memory is fixed at 16384 bytes. This size has proven to be too small for some use cases. Make the size of the memory buffer for UEFI variables customizable. Reported-by: Paulo Alcantara (SUSE) <pc@cjr.nz> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2020-12-20 10:05:38 +00:00
config EFI_VAR_BUF_SIZE
int "Memory size of the UEFI variable store"
default 16384
range 4096 2147483647
help
This defines the size in bytes of the memory area reserved for keeping
UEFI variables.
When using StandAloneMM (CONFIG_EFI_MM_COMM_TEE=y) this value should
match the value of PcdFlashNvStorageVariableSize used to compile the
StandAloneMM module.
Minimum 4096, default 16384.
efi_loader: Kconfig entries for GetTime(), SetTime() The GetTime() and the SetTime() runtime services are not obligatory. So let's make them customizable. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-31 20:56:02 +00:00
config EFI_GET_TIME
bool "GetTime() runtime service"
depends on DM_RTC
default y
help
Provide the GetTime() runtime service at boottime. This service
can be used by an EFI application to read the real time clock.
config EFI_SET_TIME
bool "SetTime() runtime service"
depends on EFI_GET_TIME
efi_loader: enable EFI_SET_TIME on sandbox and QEMU ARM Enable EFI_SET_TIME on the sandbox and QEMU ARM to ensure that we compile and test the relevant code. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-11-21 19:52:18 +00:00
default y if ARCH_QEMU || SANDBOX
efi_loader: Kconfig entries for GetTime(), SetTime() The GetTime() and the SetTime() runtime services are not obligatory. So let's make them customizable. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-31 20:56:02 +00:00
default n
help
Provide the SetTime() runtime service at boottime. This service
can be used by an EFI application to adjust the real time clock.
efi_loader: define UpdateCapsule api In this commit, skeleton functions for capsule-related API's are added under CONFIG_EFI_UPDATE_CAPSULE configuration. Detailed implementation for a specific capsule type will be added in the succeeding patches. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-11-17 00:27:55 +00:00
config EFI_HAVE_CAPSULE_SUPPORT
bool
config EFI_RUNTIME_UPDATE_CAPSULE
bool "UpdateCapsule() runtime service"
default n
select EFI_HAVE_CAPSULE_SUPPORT
help
Select this option if you want to use UpdateCapsule and
QueryCapsuleCapabilities API's.
efi_loader: capsule: add capsule_on_disk support Capsule data can be loaded into the system either via UpdateCapsule runtime service or files on a file system (of boot device). The latter case is called "capsules on disk", and actual updates will take place at the next boot time. In this commit, we will support capsule on disk mechanism. Please note that U-Boot itself has no notion of "boot device" and all the capsule files to be executed will be detected only if they are located in a specific directory, \EFI\UpdateCapsule, on a device that is identified as a boot device by "BootXXXX" variables. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-11-17 00:27:56 +00:00
config EFI_CAPSULE_ON_DISK
bool "Enable capsule-on-disk support"
select EFI_HAVE_CAPSULE_SUPPORT
default n
help
Select this option if you want to use capsule-on-disk feature,
that is, capsules can be fetched and executed from files
under a specific directory on UEFI system partition instead of
via UpdateCapsule API.
config EFI_CAPSULE_ON_DISK_EARLY
bool "Initiate capsule-on-disk at U-Boot boottime"
depends on EFI_CAPSULE_ON_DISK
default n
select EFI_SETUP_EARLY
help
Normally, without this option enabled, capsules will be
executed only at the first time of invoking one of efi command.
If this option is enabled, capsules will be enforced to be
executed as part of U-Boot initialisation so that they will
surely take place whatever is set to distro_bootcmd.
efi_loader: add firmware management protocol for raw image In this commit, a very simple firmware management protocol driver is implemented. It will take a binary image in a capsule file and apply the data using dfu backend storage drivers via dfu_write_by_alt() interface. So "dfu_alt_info" variable should be properly set to specify a device and location to be updated. Please read README.dfu. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-11-17 00:28:00 +00:00
config EFI_CAPSULE_FIRMWARE
bool
default n
efi_loader: capsule: support firmware update A capsule tagged with the guid, EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID, is handled as a firmware update object. What efi_update_capsule() basically does is to load any firmware management protocol (or fmp) drivers contained in a capsule, find out an appropriate fmp driver and then invoke its set_image() interface against each binary in a capsule. In this commit, however, loading drivers is not supported. The result of applying a capsule is set to be stored in "CapsuleXXXX" variable, but its implementation is deferred to a fmp driver. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-11-30 09:12:11 +00:00
config EFI_CAPSULE_FIRMWARE_MANAGEMENT
bool "Capsule: Firmware Management Protocol"
depends on EFI_HAVE_CAPSULE_SUPPORT
default y
help
Select this option if you want to enable capsule-based
firmware update using Firmware Management Protocol.
efi: capsule: Add support for uefi capsule authentication Add support for authenticating uefi capsules. Most of the signature verification functionality is shared with the uefi secure boot feature. The root certificate containing the public key used for the signature verification is stored as part of the device tree blob. The root certificate is stored as an efi signature list(esl) file -- this file contains the x509 certificate which is the root certificate. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org>
2020-12-30 13:57:09 +00:00
config EFI_CAPSULE_AUTHENTICATE
bool "Update Capsule authentication"
depends on EFI_CAPSULE_FIRMWARE
depends on EFI_CAPSULE_ON_DISK
depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
select SHA256
select RSA
select RSA_VERIFY
select RSA_VERIFY_WITH_PKEY
select X509_CERTIFICATE_PARSER
select PKCS7_MESSAGE_PARSER
select PKCS7_VERIFY
default n
help
Select this option if you want to enable capsule
authentication
efi_loader: add firmware management protocol for FIT image In this commit, a very simple firmware management protocol driver is implemented. It will take a common FIT image firmware in a capsule file and apply the data using dfu backend storage drivers via update_fit() interface. So "dfu_alt_info" variable should be properly set to specify a device and location to be updated. Please read README.dfu. Fit image is a common file format for firmware update on U-Boot, and this protocol works neatly just as a wrapper for one. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-11-30 09:12:12 +00:00
config EFI_CAPSULE_FIRMWARE_FIT
bool "FMP driver for FIT image"
depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
depends on FIT
select UPDATE_FIT
select DFU
efi_loader: add firmware management protocol for raw image In this commit, a very simple firmware management protocol driver is implemented. It will take a binary image in a capsule file and apply the data using dfu backend storage drivers via dfu_write_by_alt() interface. So "dfu_alt_info" variable should be properly set to specify a device and location to be updated. Please read README.dfu. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-11-17 00:28:00 +00:00
select EFI_CAPSULE_FIRMWARE
efi_loader: add firmware management protocol for FIT image In this commit, a very simple firmware management protocol driver is implemented. It will take a common FIT image firmware in a capsule file and apply the data using dfu backend storage drivers via update_fit() interface. So "dfu_alt_info" variable should be properly set to specify a device and location to be updated. Please read README.dfu. Fit image is a common file format for firmware update on U-Boot, and this protocol works neatly just as a wrapper for one. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-11-30 09:12:12 +00:00
default n
help
Select this option if you want to enable firmware management protocol
driver for FIT image
efi_loader: add firmware management protocol for raw image In this commit, a very simple firmware management protocol driver is implemented. It will take a binary image in a capsule file and apply the data using dfu backend storage drivers via dfu_write_by_alt() interface. So "dfu_alt_info" variable should be properly set to specify a device and location to be updated. Please read README.dfu. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-11-17 00:28:00 +00:00
config EFI_CAPSULE_FIRMWARE_RAW
bool "FMP driver for raw image"
depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
select DFU
select DFU_WRITE_ALT
select EFI_CAPSULE_FIRMWARE
default n
help
Select this option if you want to enable firmware management protocol
driver for raw image
efi_loader: make device path to text protocol customizable The device path to text protocol is not needed for EBBR compliance. So let's make it a customizable option. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-11 07:53:33 +00:00
config EFI_DEVICE_PATH_TO_TEXT
bool "Device path to text protocol"
default y
help
The device path to text protocol converts device nodes and paths to
human readable strings.
efi_loader: EFI_DEVICE_PATH_UTILITIES_PROTOCOL configurable Allow the EFI_DEVICE_PATH_UTILITIES_PROTOCOL to be disabled via configuration. On systems that are very tight on U-Boot image size we may want to disable the protocol. As it is required to run the UEFI Shell enable it by default. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-01-16 08:44:25 +00:00
config EFI_DEVICE_PATH_UTIL
bool "Device path utilities protocol"
default y
help
The device path utilities protocol creates and manipulates device
paths and device nodes. It is required to run the EFI Shell.
efi_loader: make EFI_DT_FIXUP_PROTOCOL configurable Allow EFI_DT_FIXUP_PROTOCOL to be disabled via configuration. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-01-16 08:33:24 +00:00
config EFI_DT_FIXUP
bool "Device tree fixup protocol"
depends on !GENERATE_ACPI_TABLE
default y
help
The EFI device-tree fix-up protocol provides a function to let the
firmware apply fix-ups. This may be used by boot loaders.
efi_loader: format Kconfig Use if/endif for dependencies to give structure to the configuration menu. Sort important settings to the top. Abbreviate the short description of EFI_LOADER_HII. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-08 21:17:38 +00:00
config EFI_LOADER_HII
bool "HII protocols"
default y
help
The Human Interface Infrastructure is a complicated framework that
allows UEFI applications to draw fancy menus and hook strings using
a translation framework.
U-Boot implements enough of its features to be able to run the UEFI
Shell, but not more than that.
efi_loader: rename Unicode collation protocol 2 variables Rename variables to make it clear they refer to the Unicode collation protocol identified by the EFI_UNICODE_PROTOCOL2_GUID. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-16 05:52:58 +00:00
config EFI_UNICODE_COLLATION_PROTOCOL2
efi_loader: make Unicode collation protocol customizable The Unicode collation protocol is not needed for EBBR compliance. So let's make it a customizable option. The Unicode capitalization table is only needed by this protocol. So let it depend on the Unicode collation protocol. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-08 21:24:26 +00:00
bool "Unicode collation protocol"
default y
help
The Unicode collation protocol is used for lexical comparisons. It is
required to run the UEFI shell.
efi_loader: rename Unicode collation protocol 2 variables Rename variables to make it clear they refer to the Unicode collation protocol identified by the EFI_UNICODE_PROTOCOL2_GUID. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-16 05:52:58 +00:00
if EFI_UNICODE_COLLATION_PROTOCOL2
efi_loader: make Unicode collation protocol customizable The Unicode collation protocol is not needed for EBBR compliance. So let's make it a customizable option. The Unicode capitalization table is only needed by this protocol. So let it depend on the Unicode collation protocol. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-08 21:24:26 +00:00
lib: charset: upper/lower case conversion Provide functions for upper and lower case conversion. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de>
2018-09-04 17:34:56 +00:00
config EFI_UNICODE_CAPITALIZATION
bool "Support Unicode capitalization"
default y
help
Select this option to enable correct handling of the capitalization of
Unicode codepoints in the range 0x0000-0xffff. If this option is not
set, only the the correct handling of the letters of the codepage
used by the FAT file system is ensured.
efi_loader: make Unicode collation protocol customizable The Unicode collation protocol is not needed for EBBR compliance. So let's make it a customizable option. The Unicode capitalization table is only needed by this protocol. So let it depend on the Unicode collation protocol. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-08 21:24:26 +00:00
endif
efi_loader: Add bounce buffer support Some hardware that is supported by U-Boot can not handle DMA above 32bits. For these systems, we need to come up with a way to expose the disk interface in a safe way. This patch implements EFI specific bounce buffers. For non-EFI cases, this apparently was no issue so far, since we can just define our environment variables conveniently. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-05-11 16:25:48 +00:00
config EFI_LOADER_BOUNCE_BUFFER
bool "EFI Applications use bounce buffers for DMA operations"
efi_loader: format Kconfig Use if/endif for dependencies to give structure to the configuration menu. Sort important settings to the top. Abbreviate the short description of EFI_LOADER_HII. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-08 21:17:38 +00:00
depends on ARM64
efi_loader: Add bounce buffer support Some hardware that is supported by U-Boot can not handle DMA above 32bits. For these systems, we need to come up with a way to expose the disk interface in a safe way. This patch implements EFI specific bounce buffers. For non-EFI cases, this apparently was no issue so far, since we can just define our environment variables conveniently. Signed-off-by: Alexander Graf <agraf@suse.de>
2016-05-11 16:25:48 +00:00
default n
help
Some hardware does not support DMA to full 64bit addresses. For this
hardware we can create a bounce buffer so that payloads don't have to
worry about platform details.
efi_loader: Make HII a config option Heinrich ran into issues with HII and iPXE which lead to #SErrors on his Odroid-C2 system. We definitely do not want to regress just yet, so let's not expose the HII protocols by default. Instead, let's make it a config option that people can play with This way, we can stabilize the code in tree without breaking any users. Once someone figures out, why this breaks iPXE (probably a NULL dereference), we can enable it by default. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> --- v1 -> v2: - Remove HII selftest as well v2 -> v3: - Make config option
2019-02-11 14:24:00 +00:00
efi_loader: format Kconfig Use if/endif for dependencies to give structure to the configuration menu. Sort important settings to the top. Abbreviate the short description of EFI_LOADER_HII. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-08 21:17:38 +00:00
config EFI_PLATFORM_LANG_CODES
string "Language codes supported by firmware"
default "en-US"
efi_loader: Make HII a config option Heinrich ran into issues with HII and iPXE which lead to #SErrors on his Odroid-C2 system. We definitely do not want to regress just yet, so let's not expose the HII protocols by default. Instead, let's make it a config option that people can play with This way, we can stabilize the code in tree without breaking any users. Once someone figures out, why this breaks iPXE (probably a NULL dereference), we can enable it by default. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> --- v1 -> v2: - Remove HII selftest as well v2 -> v3: - Make config option
2019-02-11 14:24:00 +00:00
help
efi_loader: format Kconfig Use if/endif for dependencies to give structure to the configuration menu. Sort important settings to the top. Abbreviate the short description of EFI_LOADER_HII. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-08 21:17:38 +00:00
This value is used to initialize the PlatformLangCodes variable. Its
value is a semicolon (;) separated list of language codes in native
RFC 4646 format, e.g. "en-US;de-DE". The first language code is used
to initialize the PlatformLang variable.
efi_loader: Make HII a config option Heinrich ran into issues with HII and iPXE which lead to #SErrors on his Odroid-C2 system. We definitely do not want to regress just yet, so let's not expose the HII protocols by default. Instead, let's make it a config option that people can play with This way, we can stabilize the code in tree without breaking any users. Once someone figures out, why this breaks iPXE (probably a NULL dereference), we can enable it by default. Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Alexander Graf <agraf@suse.de> --- v1 -> v2: - Remove HII selftest as well v2 -> v3: - Make config option
2019-02-11 14:24:00 +00:00
efi_loader: decision on EFI_RT_SUPPORTED_RESET_SYSTEM Move the logic determining which board supports reset at runtime to Kconfig. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-07-05 16:12:16 +00:00
config EFI_HAVE_RUNTIME_RESET
# bool "Reset runtime service is available"
bool
default y
sandbox: implement runtime system reset Implement a reset function that we can call after ExitBootServices(), when all driver model devices are gone. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2020-12-02 15:22:11 +00:00
depends on ARCH_BCM283X || FSL_LAYERSCAPE || PSCI_RESET || \
SANDBOX || SYSRESET_X86
efi_loader: decision on EFI_RT_SUPPORTED_RESET_SYSTEM Move the logic determining which board supports reset at runtime to Kconfig. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-07-05 16:12:16 +00:00
efi_loader: re-enable GRUB workaround on 32bit ARM GRUB on ARM 32bit prior to version 2.04 lacks proper handling of caches. In U-Boot v2019.04 a workaround for this was inadvertently removed. The workaround is currently also needed for booting on systems with caches that cannot be managed via CP15 (e.g. with an i.MX6 CPU). Re-enable the workaround and make it customizable. Fixes: f69d63fae281 ("efi_loader: use efi_start_image() for bootefi") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-07-22 20:04:36 +00:00
config EFI_GRUB_ARM32_WORKAROUND
bool "Workaround for GRUB on 32bit ARM"
efi_loader: QEMU CONFIG_EFI_GRUB_ARM32_WORKAROUND=n CONFIG_EFI_GRUB_ARM32 is only needed for architectures with caches that are not managed via CP15 (or for some outdated buggy versions of GRUB). It makes more sense to disable the setting per architecture than per defconfig. Move QEMU's CONFIG_EFI_GRUB_ARM32_WORKAROUND=n from defconfig to Kconfig. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-09-17 17:09:23 +00:00
default n if ARCH_QEMU
efi_loader: re-enable GRUB workaround on 32bit ARM GRUB on ARM 32bit prior to version 2.04 lacks proper handling of caches. In U-Boot v2019.04 a workaround for this was inadvertently removed. The workaround is currently also needed for booting on systems with caches that cannot be managed via CP15 (e.g. with an i.MX6 CPU). Re-enable the workaround and make it customizable. Fixes: f69d63fae281 ("efi_loader: use efi_start_image() for bootefi") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-07-22 20:04:36 +00:00
default y
depends on ARM && !ARM64
help
GRUB prior to version 2.04 requires U-Boot to disable caches. This
workaround currently is also needed on systems with caches that
cannot be managed via CP15.
efi: qemu: arm64: Add efi_rng_protocol implementation for the platform Add support for the EFI_RNG_PROTOCOL routines for the qemu arm64 platform. EFI_RNG_PROTOCOL is an uefi boottime service which is invoked by the efi stub in the kernel for getting random seed for kaslr. The routines are platform specific, and use the virtio-rng device on the platform to get random data. The feature can be enabled through the following config CONFIG_EFI_RNG_PROTOCOL Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Changed SPDX header to use /* instead of //. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-12-28 18:31:05 +00:00
config EFI_RNG_PROTOCOL
bool "EFI_RNG_PROTOCOL support"
depends on DM_RNG
efi_loader: enable RNG if DM_RNG is enabled Enable EFI_RNG_PROTOCOL by default if DM_RNG is set. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> Acked-by: Sughosh Ganu <sughosh.ganu@linaro.org> Remove superfluous 'if DM_RNG' Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-04-01 10:15:01 +00:00
default y
efi: qemu: arm64: Add efi_rng_protocol implementation for the platform Add support for the EFI_RNG_PROTOCOL routines for the qemu arm64 platform. EFI_RNG_PROTOCOL is an uefi boottime service which is invoked by the efi stub in the kernel for getting random seed for kaslr. The routines are platform specific, and use the virtio-rng device on the platform to get random data. The feature can be enabled through the following config CONFIG_EFI_RNG_PROTOCOL Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Changed SPDX header to use /* instead of //. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-12-28 18:31:05 +00:00
help
efi_loader: EFI_RNG_PROTOCOL Do not use quotation marks for Kconfig help text. Replace rng abbreviation by full words. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-02-14 22:28:58 +00:00
Provide a EFI_RNG_PROTOCOL implementation using the hardware random
number generator of the platform.
efi_loader: Add basic EFI_TCG2_PROTOCOL support Since U-boot EFI implementation is getting richer it makes sense to add support for EFI_TCG2_PROTOCOL taking advantage of any hardware TPM available on the device. This is the initial implementation of the protocol which only adds support for GetCapability(). It's limited in the newer and safer TPMv2 devices. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-11-11 09:18:11 +00:00
config EFI_TCG2_PROTOCOL
bool "EFI_TCG2_PROTOCOL support"
depends on TPM_V2
help
Provide a EFI_TCG2_PROTOCOL implementation using the TPM hardware
of the platform.
efi: qemu: arm64: Add efi_rng_protocol implementation for the platform Add support for the EFI_RNG_PROTOCOL routines for the qemu arm64 platform. EFI_RNG_PROTOCOL is an uefi boottime service which is invoked by the efi stub in the kernel for getting random seed for kaslr. The routines are platform specific, and use the virtio-rng device on the platform to get random data. The feature can be enabled through the following config CONFIG_EFI_RNG_PROTOCOL Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Changed SPDX header to use /* instead of //. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-12-28 18:31:05 +00:00
efi_loader: Introduce eventlog support for TCG2_PROTOCOL In the previous patches we only introduced a minimal subset of the EFI_TCG2_PROTOCOL protocol implementing GetCapability(). So let's continue adding features to it, introducing the GetEventLog() and HashLogExtendEvent() functions. In order to do that we first need to construct the eventlog in memory, specifically in EFI_BOOT_SERVICES_DATA memory and a configuration table from EFI_ACPI_MEMORY_NVS. U-Boot won't currently add any events to the log or measure any components, but will expose the necessary EFI APIs for applications to do so. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2020-11-30 09:47:40 +00:00
config EFI_TCG2_PROTOCOL_EVENTLOG_SIZE
int "EFI_TCG2_PROTOCOL EventLog size"
depends on EFI_TCG2_PROTOCOL
default 4096
help
Define the size of the EventLog for EFI_TCG2_PROTOCOL. Note that
this is going to be allocated twice. One for the eventlog it self
and one for the configuration table that is required from the spec
efi_loader: Implement FileLoad2 for initramfs loading Following kernel's proposal for an arch-agnostic initrd loading mechanism [1] let's implement the U-boot counterpart. This new approach has a number of advantages compared to what we did up to now. The file is loaded into memory only when requested limiting the area of TOCTOU attacks. Users will be allowed to place the initramfs file on any u-boot accessible partition instead of just the ESP one. Finally this is an attempt of a generic interface across architectures in the linux kernel so it makes sense to support that. The file location is intentionally only supported as a config option argument(CONFIG_EFI_INITRD_FILESPEC), in an effort to enhance security. Although U-boot is not responsible for verifying the integrity of the initramfs, we can enhance the offered security by only accepting a built-in option, which will be naturally verified by UEFI Secure Boot. This can easily change in the future if needed and configure that via ENV or UEFI variable. [1] https://lore.kernel.org/linux-efi/20200207202637.GA3464906@rani.riverdale.lan/T/#m4a25eb33112fab7a22faa0fd65d4d663209af32f Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2020-02-21 07:55:45 +00:00
config EFI_LOAD_FILE2_INITRD
bool "EFI_FILE_LOAD2_PROTOCOL for Linux initial ramdisk"
default n
help
Expose a EFI_FILE_LOAD2_PROTOCOL that the Linux UEFI stub can
use to load the initial ramdisk. Once this is enabled using
initrd=<ramdisk> will stop working.
config EFI_INITRD_FILESPEC
string "initramfs path"
default "host 0:1 initrd"
depends on EFI_LOAD_FILE2_INITRD
help
Full path of the initramfs file, e.g. mmc 0:2 initramfs.cpio.gz.
efi_loader: add CONFIG_EFI_SECURE_BOOT config option Under this configuration, UEFI secure boot support will be added in later patches. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-14 02:51:38 +00:00
config EFI_SECURE_BOOT
bool "Enable EFI secure boot support"
depends on EFI_LOADER
select SHA256
select RSA
select RSA_VERIFY_WITH_PKEY
select IMAGE_SIGN_INFO
select ASYMMETRIC_KEY_TYPE
select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
select X509_CERTIFICATE_PARSER
select PKCS7_MESSAGE_PARSER
efi_loader: signature: rework for intermediate certificates support In this commit, efi_signature_verify(with_sigdb) will be re-implemented using pcks7_verify_one() in order to support certificates chain, where the signer's certificate will be signed by an intermediate CA (certificate authority) and the latter's certificate will also be signed by another CA and so on. What we need to do here is to search for certificates in a signature, build up a chain of certificates and verify one by one. pkcs7_verify_one() handles most of these steps except the last one. pkcs7_verify_one() returns, if succeeded, the last certificate to verify, which can be either a self-signed one or one that should be signed by one of certificates in "db". Re-worked efi_signature_verify() will take care of this step. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-07-21 10:35:22 +00:00
select PKCS7_VERIFY
efi_loader: add CONFIG_EFI_SECURE_BOOT config option Under this configuration, UEFI secure boot support will be added in later patches. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2020-04-14 02:51:38 +00:00
default n
help
Select this option to enable EFI secure boot support.
Once SecureBoot mode is enforced, any EFI binary can run only if
it is signed with a trusted key. To do that, you need to install,
at least, PK, KEK and db.
efi_loader: format Kconfig Use if/endif for dependencies to give structure to the configuration menu. Sort important settings to the top. Abbreviate the short description of EFI_LOADER_HII. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2019-05-08 21:17:38 +00:00
endif
Reference in a new issue Copy permalink