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

490 lines
16 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: require CONFIG_BLK The move to driver model should by now be completed. To be able to remove pre-driver model code from our block IO code require CONFIG_BLK=y for UEFI support. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-09-07 06:56:47 +00:00
depends on BLK
efi: Create a 64-bit app Most modern platforms use 64-bit EFI so it is useful to have a U-Boot app that runs under that. Add a (non-functional) build for this. Note that --whole-archive causes the gcc 9.2 linker to crash, so disable this for now. Once this is resolved, things should work. For now, avoid mentioning the documentation for the 64-bit app, since it does not work. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-11-04 03:09:07 +00:00
depends on !EFI_APP
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
lib: fix selection of CONFIG_CHARSET lib/charset.c is not optional for EFI_APP || EFI_LOADER || UFS || UT_UNICODE. These must select CONFIG_CHARSET. Fixes: 726cd9836db0 ("efi: Make unicode printf available to the app") Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-05-02 04:27:00 +00:00
select CHARSET
event: Correct dependencies on the EVENT framework The event framework is just that, a framework. Enabling it by itself does nothing, so we shouldn't ask the user about it. Reword (and correct typos) around this the option and help text. This also applies to DM_EVENT and EVENT_DYNAMIC. Only EVENT_DEBUG and CMD_EVENT should be visible to the user to select, when EVENT is selected. With this, it's time to address the larger problems. When functionality uses events, typically via EVENT_SPY, the appropriate framework then must be select'd and NOT imply'd. As the functionality will cease to work (and so, platforms will fail to boot) this is non-optional and where select is appropriate. Audit the current users of EVENT_SPY to have a more fine-grained approach to select'ing the framework where used. Also ensure the current users of event_register and also select EVENT_DYNAMIC. Cc: AKASHI Takahiro <takahiro.akashi@linaro.org> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Reported-by: Oliver Graute <Oliver.Graute@kococonnector.com> Reported-by: Francesco Dolcini <francesco.dolcini@toradex.com> Fixes: 7fe32b3442f0 ("event: Convert arch_cpu_init_dm() to use events") Fixes: 42fdcebf859f ("event: Convert misc_init_f() to use events") Fixes: c5ef2025579e ("dm: fix DM_EVENT dependencies") Signed-off-by: Tom Rini <trini@konsulko.com> Tested-by: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Fabio Estevam <festevam@denx.de>
2023-01-16 20:46:49 +00:00
# We need to send DM events, dynamically, in the EFI block driver
efi_loader: disk: a helper function to create efi_disk objects from udevice Add efi_disk_probe() function. This function creates an efi_disk object for a raw disk device (UCLASS_BLK) and additional objects for related partitions (UCLASS_PARTITION). So this function is expected to be called through driver model's "probe" interface every time one raw disk device is detected and activated. We assume that partition devices (UCLASS_PARTITION) have been created when this function is invoked. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2022-04-19 01:05:12 +00:00
select DM_EVENT
select EVENT_DYNAMIC
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
efi_loader: PARTITION_UUIDS should be optional In the current implementation, partition table support (either GPT or DOS) is not mandatory. So CONFIG_PARTITION_UUIDS should not be enabled (selected) unconditionally. Fixes: commit 17f8cda505e3 ("efi_loader: set partition GUID in device path for SIG_TYPE_GUID") Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-04-19 01:01:56 +00:00
imply PARTITION_UUIDS
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: 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: Rearrange the Kconfig for CMD_BOOTEFI_BOOTMGR The command should not be used to enable library functionality. Add a new BOOTEFI_BOOTMGR Kconfig for that. Adjust the conditions so that the same code is built. Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2023-10-26 18:31:20 +00:00
config BOOTEFI_BOOTMGR
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
bool "UEFI Boot Manager"
default y
bootstd: Allow bootmeths to be marked as global The current way of handling things like EFI bootmgr is a bit odd, since that bootmeth handles selection of the bootdev itself. VBE needs to work the same way, so we should support it properly. Add a flag that indicates that the bootmeth is global, rather than being invoked on each bootdev. Provide a helper to read a bootflow from the bootmeth. Signed-off-by: Simon Glass <sjg@chromium.org>
2022-07-30 21:52:21 +00:00
select BOOTMETH_GLOBAL if BOOTSTD
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
help
Select this option if you want to select the UEFI binary to be booted
efi: Rearrange the Kconfig for CMD_BOOTEFI_BOOTMGR The command should not be used to enable library functionality. Add a new BOOTEFI_BOOTMGR Kconfig for that. Adjust the conditions so that the same code is built. Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2023-10-26 18:31:20 +00:00
via UEFI variables Boot####, BootOrder, and BootNext. You should also
normally enable CMD_BOOTEFI_BOOTMGR so that the command is available.
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
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
arm_ffa: efi: introduce FF-A MM communication Add MM communication support using FF-A transport This feature allows accessing MM partitions services through EFI MM communication protocol. MM partitions such as StandAlonneMM or smm-gateway secure partitions which reside in secure world. An MM shared buffer and a door bell event are used to exchange the data. The data is used by EFI services such as GetVariable()/SetVariable() and copied from the communication buffer to the MM shared buffer. The secure partition is notified about availability of data in the MM shared buffer by an FF-A message (door bell). On such event, MM SP can read the data and updates the MM shared buffer with the response data. The response data is copied back to the communication buffer and consumed by the EFI subsystem. MM communication protocol supports FF-A 64-bit direct messaging. We tested the FF-A MM communication on the Corstone-1000 platform. We ran the UEFI SCT test suite containing EFI setVariable, getVariable and getNextVariable tests which involve FF-A MM communication and all tests are passing with the current changes. We made the SCT test reports (part of the ACS results) public following the latest Corstone-1000 platform software release. Please find the test reports at [1]. [1]: https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-test-report/-/tree/master/embedded-a/corstone1000/CORSTONE1000-2023.06/acs_results_fpga.zip Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Tested-by: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2023-08-04 13:33:44 +00:00
bool "UEFI variables storage service via the trusted world"
Revert "Merge branch '2023-07-24-introduce-FF-A-suppport'" This reverts commit d927d1a80843e1c3e2a3f0b8f6150790bef83da1, reversing changes made to c07ad9520c6190070513016fdb495d4703a4a853. These changes do not pass CI currently. Signed-off-by: Tom Rini <trini@konsulko.com>
2023-07-24 23:51:05 +00:00
depends on OPTEE
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
help
arm_ffa: efi: introduce FF-A MM communication Add MM communication support using FF-A transport This feature allows accessing MM partitions services through EFI MM communication protocol. MM partitions such as StandAlonneMM or smm-gateway secure partitions which reside in secure world. An MM shared buffer and a door bell event are used to exchange the data. The data is used by EFI services such as GetVariable()/SetVariable() and copied from the communication buffer to the MM shared buffer. The secure partition is notified about availability of data in the MM shared buffer by an FF-A message (door bell). On such event, MM SP can read the data and updates the MM shared buffer with the response data. The response data is copied back to the communication buffer and consumed by the EFI subsystem. MM communication protocol supports FF-A 64-bit direct messaging. We tested the FF-A MM communication on the Corstone-1000 platform. We ran the UEFI SCT test suite containing EFI setVariable, getVariable and getNextVariable tests which involve FF-A MM communication and all tests are passing with the current changes. We made the SCT test reports (part of the ACS results) public following the latest Corstone-1000 platform software release. Please find the test reports at [1]. [1]: https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-test-report/-/tree/master/embedded-a/corstone1000/CORSTONE1000-2023.06/acs_results_fpga.zip Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Tested-by: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2023-08-04 13:33:44 +00:00
Allowing access to the MM SP services (SPs such as StandAlonneMM, smm-gateway).
When using the u-boot OP-TEE driver, StandAlonneMM is supported.
When using the u-boot FF-A driver any MM SP is supported.
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
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.
arm_ffa: efi: introduce FF-A MM communication Add MM communication support using FF-A transport This feature allows accessing MM partitions services through EFI MM communication protocol. MM partitions such as StandAlonneMM or smm-gateway secure partitions which reside in secure world. An MM shared buffer and a door bell event are used to exchange the data. The data is used by EFI services such as GetVariable()/SetVariable() and copied from the communication buffer to the MM shared buffer. The secure partition is notified about availability of data in the MM shared buffer by an FF-A message (door bell). On such event, MM SP can read the data and updates the MM shared buffer with the response data. The response data is copied back to the communication buffer and consumed by the EFI subsystem. MM communication protocol supports FF-A 64-bit direct messaging. We tested the FF-A MM communication on the Corstone-1000 platform. We ran the UEFI SCT test suite containing EFI setVariable, getVariable and getNextVariable tests which involve FF-A MM communication and all tests are passing with the current changes. We made the SCT test reports (part of the ACS results) public following the latest Corstone-1000 platform software release. Please find the test reports at [1]. [1]: https://gitlab.arm.com/arm-reference-solutions/arm-reference-solutions-test-report/-/tree/master/embedded-a/corstone1000/CORSTONE1000-2023.06/acs_results_fpga.zip Signed-off-by: Abdellatif El Khlifi <abdellatif.elkhlifi@arm.com> Tested-by: Gowtham Suresh Kumar <gowtham.sureshkumar@arm.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Jens Wiklander <jens.wiklander@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com>
2023-08-04 13:33:44 +00:00
When ARM_FFA_TRANSPORT is used, dispatch all UEFI variable related
operations to the MM SP running in the secure world.
A door bell mechanism is used to notify the SP when there is data in the shared
MM buffer. The data is copied by u-boot to the shared buffer before issuing
the door bell event.
config FFA_SHARED_MM_BUF_SIZE
int "Memory size of the shared MM communication buffer"
depends on EFI_MM_COMM_TEE && ARM_FFA_TRANSPORT
help
This defines the size in bytes of the memory area reserved for the shared
buffer used for communication between the MM feature in U-Boot and
the MM SP in secure world.
The size of the memory region must be a multiple of the size of the maximum
translation granule size that is specified in the ID_AA64MMFR0_EL1 System register.
It is assumed that the MM SP knows the size of the shared MM communication buffer.
config FFA_SHARED_MM_BUF_OFFSET
int "Data offset in the shared MM communication buffer"
depends on EFI_MM_COMM_TEE && ARM_FFA_TRANSPORT
help
This defines the offset in bytes of the data read or written to in the shared
buffer by the MM SP.
config FFA_SHARED_MM_BUF_ADDR
hex "Define the address of the shared MM communication buffer"
depends on EFI_MM_COMM_TEE && ARM_FFA_TRANSPORT
help
This defines the address of the shared MM communication buffer
used for communication between the MM feature in U-Boot and
the MM SP in secure world.
It is assumed that the MM SP knows the address of the shared MM communication buffer.
efi_loader: optional persistence of variables Since be66b89da306 ("efi_loader: configuration of variables store") the choice of EFI_VARIABLE_FILE_STORE or EFI_MM_COMM_TEE is mutually-exclusive, however efi_var_to_file also allows for "neither". Provide an additional Kconfig option. Signed-off-by: Tom Saeger <tom.saeger@oracle.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-03-22 21:21:10 +00:00
config EFI_VARIABLE_NO_STORE
bool "Don't persist non-volatile UEFI variables"
help
If you choose this option, non-volatile variables cannot be persisted.
You could still provide non-volatile variables via
EFI_VARIABLES_PRESEED.
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
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"
efi_loader: optional persistence of variables Since be66b89da306 ("efi_loader: configuration of variables store") the choice of EFI_VARIABLE_FILE_STORE or EFI_MM_COMM_TEE is mutually-exclusive, however efi_var_to_file also allows for "neither". Provide an additional Kconfig option. Signed-off-by: Tom Saeger <tom.saeger@oracle.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-03-22 21:21:10 +00:00
depends on !EFI_MM_COMM_TEE
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
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"
efi_loader: Increase default variable store size to 64KiB Debian's arm64 UEFI Secure Boot shim makes the EFI variable store run out of space while mirroring its MOK database to variables. This can be observed in QEMU like so: $ tools/buildman/buildman -o build/qemu_arm64 --boards=qemu_arm64 -w $ cd build/qemu_arm64 $ curl -L -o debian.iso \ https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/debian-12.0.0-arm64-netinst.iso $ qemu-system-aarch64 \ -nographic -bios u-boot.bin \ -machine virt -cpu cortex-a53 -m 1G -smp 2 \ -drive if=virtio,file=debian.iso,index=0,format=raw,readonly=on,media=cdrom [...] => # interrupt autoboot => env set -e -bs -nv -rt -guid 605dab50-e046-4300-abb6-3dd810dd8b23 SHIM_VERBOSE 1 => boot [...] mok.c:296:mirror_one_esl() SetVariable("MokListXRT43", ... varsz=0x4C) = Out of Resources mok.c:452:mirror_mok_db() esd:0x7DB92D20 adj:0x30 Failed to set MokListXRT: Out of Resources mok.c:767:mirror_one_mok_variable() mirror_mok_db("MokListXRT", datasz=17328) returned Out of Resources mok.c:812:mirror_one_mok_variable() returning Out of Resources Could not create MokListXRT: Out of Resources [...] Welcome to GRUB! This would normally be fine as shim would continue to run grubaa64.efi, but shim's error handling code for this case has a bug [1] that causes a synchronous abort on at least chromebook_kevin (but apparently not on QEMU arm64). Double the default variable store size so the variables fit. There is a note about this value matching PcdFlashNvStorageVariableSize when EFI_MM_COMM_TEE is enabled, so keep the old default in that case. [1] https://github.com/rhboot/shim/pull/577 Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2023-07-08 15:21:12 +00:00
default 16384 if EFI_MM_COMM_TEE
default 65536
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
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.
efi_loader: Increase default variable store size to 64KiB Debian's arm64 UEFI Secure Boot shim makes the EFI variable store run out of space while mirroring its MOK database to variables. This can be observed in QEMU like so: $ tools/buildman/buildman -o build/qemu_arm64 --boards=qemu_arm64 -w $ cd build/qemu_arm64 $ curl -L -o debian.iso \ https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/debian-12.0.0-arm64-netinst.iso $ qemu-system-aarch64 \ -nographic -bios u-boot.bin \ -machine virt -cpu cortex-a53 -m 1G -smp 2 \ -drive if=virtio,file=debian.iso,index=0,format=raw,readonly=on,media=cdrom [...] => # interrupt autoboot => env set -e -bs -nv -rt -guid 605dab50-e046-4300-abb6-3dd810dd8b23 SHIM_VERBOSE 1 => boot [...] mok.c:296:mirror_one_esl() SetVariable("MokListXRT43", ... varsz=0x4C) = Out of Resources mok.c:452:mirror_mok_db() esd:0x7DB92D20 adj:0x30 Failed to set MokListXRT: Out of Resources mok.c:767:mirror_one_mok_variable() mirror_mok_db("MokListXRT", datasz=17328) returned Out of Resources mok.c:812:mirror_one_mok_variable() returning Out of Resources Could not create MokListXRT: Out of Resources [...] Welcome to GRUB! This would normally be fine as shim would continue to run grubaa64.efi, but shim's error handling code for this case has a bug [1] that causes a synchronous abort on at least chromebook_kevin (but apparently not on QEMU arm64). Double the default variable store size so the variables fit. There is a note about this value matching PcdFlashNvStorageVariableSize when EFI_MM_COMM_TEE is enabled, so keep the old default in that case. [1] https://github.com/rhboot/shim/pull/577 Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2023-07-08 15:21:12 +00:00
Minimum 4096, default 65536, or 16384 when using StandAloneMM.
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
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
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: Avoid overwriting previous outputs on console screen clearing Before clearing the screen, ensure that no previous output of firmware or UEFI programs will be overwritten on serial devices or other streaming consoles. This helps generating complete boot logs. Tested regarding multi-output against qemu-x86_defconfig. Still, there were remaining concerns about side effects, so this is provided as an opt-in feature. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2023-01-18 21:24:59 +00:00
config EFI_SCROLL_ON_CLEAR_SCREEN
bool "Avoid overwriting previous output on clear screen"
help
Instead of erasing the screen content when the console screen should
be cleared, emit blank new lines so that previous output is scrolled
out of sight rather than overwritten. On serial consoles this allows
to capture complete boot logs (except for interactive menus etc.)
and can ease debugging related issues.
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"
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"
efi_loader: Use sysreset instead of reset command Use sysreset_walk_halt() directly from reset-after-capsule-on-disk feature to reboot (cold reset) machine instead of using reset command interface, since this is not a command. Note that this will make CONFIG_EFI_CAPSULE_ON_DISK depending on the CONFIG_SYSRESET. Signed-off-by: Masami Hiramatsu <masami.hiramatsu@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Simon Glass <sjg@chromium.org>
2022-03-21 13:37:56 +00:00
depends on SYSRESET
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
select EFI_HAVE_CAPSULE_SUPPORT
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.
efi_loader: Allow capsule update on-disk without checking OsIndications Although U-Boot supports capsule update on-disk, it's lack of support for SetVariable at runtime prevents applications like fwupd from using it. In order to perform the capsule update on-disk the spec says that the OS must copy the capsule to the \EFI\UpdateCapsule directory and set a bit in the OsIndications variable. The firmware then checks for the EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED bit in OsIndications variable, which is set by the submitter to trigger processing of the capsule on the next reboot. Let's add a config option which ignores the bit and just relies on the capsule being present. Since U-Boot deletes the capsule while processing it, we won't end up applying it multiple times. Note that this is allowed for all capsules. In the future, once authenticated capsules are fully supported, we can limit the functionality to those only. Signed-off-by: apalos <ilias.apalodimas@linaro.org> Reword Kconfig description. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-06-29 04:55:51 +00:00
config EFI_IGNORE_OSINDICATIONS
bool "Ignore OsIndications for CapsuleUpdate on-disk"
depends on EFI_CAPSULE_ON_DISK
help
There are boards where U-Boot does not support SetVariable at runtime.
Select this option if you want to use the capsule-on-disk feature
without setting the EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED
flag in variable OsIndications.
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_EARLY
bool "Initiate capsule-on-disk at U-Boot boottime"
depends on EFI_CAPSULE_ON_DISK
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
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_loader: Force a single FMP instance per hardware store Chapter 23 of the EFI spec (rev 2.9) says: "A specific updatable hardware firmware store must be represented by exactly one FMP instance". This is not the case for us, since both of our FMP protocols can be installed at the same time because they are controlled by a single 'dfu_alt_info' env variable. So make the config options depend on each other and allow the user to install one of them at any given time. If we fix the meta-data provided by the 'dfu_alt_info' in the future, to hint about the capsule type (fit or raw) we can revise this and enable both FMPs to be installed, as long as they target different firmware hardware stores Note that we are not using a Kconfig 'choice' on purpose, since we want to allow both of those to be installed and tested in sandbox Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-06-22 14:38:52 +00:00
config EFI_CAPSULE_FIRMWARE_FIT
bool "FMP driver for FIT images"
depends on FIT
depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
select UPDATE_FIT
select DFU
efi: Define set_dfu_alt_info() for boards with UEFI capsule update enabled Currently, there are a bunch of boards which enable the UEFI capsule update feature. The actual update of the firmware images is done through the dfu framework which uses the dfu_alt_info environment variable for getting information on the update, like device, partition number/address etc. The dfu framework allows the variable to be set through the set_dfu_alt_info function defined by the platform, or if the function is not defined, it gets the variable from the environment. Using the value set in the environment is not very robust, since the variable can be modified from the u-boot command line and this can cause an incorrect update. To prevent this from happening, define the set_dfu_alt_info function when the capsule update feature is enabled. A weak function is defined which sets the dfu_alt_info environment variable by getting the string for the variable from the platform. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
2022-04-15 05:59:37 +00:00
select SET_DFU_ALT_INFO
efi_loader: Force a single FMP instance per hardware store Chapter 23 of the EFI spec (rev 2.9) says: "A specific updatable hardware firmware store must be represented by exactly one FMP instance". This is not the case for us, since both of our FMP protocols can be installed at the same time because they are controlled by a single 'dfu_alt_info' env variable. So make the config options depend on each other and allow the user to install one of them at any given time. If we fix the meta-data provided by the 'dfu_alt_info' in the future, to hint about the capsule type (fit or raw) we can revise this and enable both FMPs to be installed, as long as they target different firmware hardware stores Note that we are not using a Kconfig 'choice' on purpose, since we want to allow both of those to be installed and tested in sandbox Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-06-22 14:38:52 +00:00
select EFI_CAPSULE_FIRMWARE
help
Select this option if you want to enable firmware management protocol
driver for FIT image
config EFI_CAPSULE_FIRMWARE_RAW
bool "FMP driver for raw images"
depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
depends on SANDBOX || (!SANDBOX && !EFI_CAPSULE_FIRMWARE_FIT)
select DFU_WRITE_ALT
select DFU
efi: Define set_dfu_alt_info() for boards with UEFI capsule update enabled Currently, there are a bunch of boards which enable the UEFI capsule update feature. The actual update of the firmware images is done through the dfu framework which uses the dfu_alt_info environment variable for getting information on the update, like device, partition number/address etc. The dfu framework allows the variable to be set through the set_dfu_alt_info function defined by the platform, or if the function is not defined, it gets the variable from the environment. Using the value set in the environment is not very robust, since the variable can be modified from the u-boot command line and this can cause an incorrect update. To prevent this from happening, define the set_dfu_alt_info function when the capsule update feature is enabled. A weak function is defined which sets the dfu_alt_info environment variable by getting the string for the variable from the platform. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Masami Hiramatsu <masami.hiramatsu@linaro.org>
2022-04-15 05:59:37 +00:00
select SET_DFU_ALT_INFO
efi_loader: Force a single FMP instance per hardware store Chapter 23 of the EFI spec (rev 2.9) says: "A specific updatable hardware firmware store must be represented by exactly one FMP instance". This is not the case for us, since both of our FMP protocols can be installed at the same time because they are controlled by a single 'dfu_alt_info' env variable. So make the config options depend on each other and allow the user to install one of them at any given time. If we fix the meta-data provided by the 'dfu_alt_info' in the future, to hint about the capsule type (fit or raw) we can revise this and enable both FMPs to be installed, as long as they target different firmware hardware stores Note that we are not using a Kconfig 'choice' on purpose, since we want to allow both of those to be installed and tested in sandbox Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-06-22 14:38:52 +00:00
select EFI_CAPSULE_FIRMWARE
help
Select this option if you want to enable firmware management protocol
driver for raw image
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
efi_loader: Work-around build issue due to missing hash_calculate() The hash_calculate() symbol is provided by hash-checksum.c. It depends on hash_progressive_lookup_algo(), provided when CONFIG_HASH=y. The issue is that hash_calculate() is used by the efi_loader, irregardless of CONFIG_FIT_SIGNATURE. As pointed out in commit 87316da05f2f ("lib: introduce HASH_CALCULATE option"), enabling hash_calculate() based on CONFIG_FIT_SIGNATURE is incorrect. To resolve this, use CONFIG_HASH as the compile switch for hash-checksum.c. This ensures that all dependencies are compiled, and is the most natural Kconfig to use. There is the issue of having to 'select HASH' in a couple of places that already 'select SHA256'. This is a deeper problem with how hashes are organized, and fixing it is beyonf the scope of this change. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Acked-by: Masahisa Kojima <masahisa.kojima@linaro.org>
2021-05-24 19:28:57 +00:00
select HASH
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
select SHA256
select RSA
select RSA_VERIFY
select RSA_VERIFY_WITH_PKEY
select X509_CERTIFICATE_PARSER
select PKCS7_MESSAGE_PARSER
select PKCS7_VERIFY
efi_loader: Kconfig: Select IMAGE_SIGN_INFO when capsule authentication is enabled Enable building of the crypto helper functions used during capsule authentication by selecting IMAGE_SIGN_INFO. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-04-07 11:53:31 +00:00
select IMAGE_SIGN_INFO
efi_loader: expose efi_image_parse() even if UEFI Secure Boot is disabled This is preparation for PE/COFF measurement support. PE/COFF image hash calculation is same in both UEFI Secure Boot image verification and measurement in measured boot. PE/COFF image parsing functions are gathered into efi_image_loader.c, and exposed even if UEFI Secure Boot is not enabled. This commit also adds the EFI_SIGNATURE_SUPPORT option to decide if efi_signature.c shall be compiled. Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-05-14 00:53:36 +00:00
select EFI_SIGNATURE_SUPPORT
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
help
Select this option if you want to enable capsule
authentication
efi_loader: set CapsuleMax from CONFIG_EFI_CAPSULE_MAX Adds CONFIG_EFI_CAPSULE_MAX to configure the max index value used in EFI capsule reports. Prior to this change is the hard coded value was 65535 which would exceed available storage for variables. Now the default value is 15 which should work fine with most systems. Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
2023-02-16 17:21:41 +00:00
config EFI_CAPSULE_MAX
int "Max value for capsule index"
default 15
range 0 65535
help
Select the max capsule index value used for capsule report
variables. This value is used to create CapsuleMax variable.
scripts/Makefile.lib: Embed capsule public key in platform's dtb The EFI capsule authentication logic in u-boot expects the public key in the form of an EFI Signature List(ESL) to be provided as part of the platform's dtb. Currently, the embedding of the ESL file into the dtb needs to be done manually. Add a target for generating a dtsi file which contains the signature node with the ESL file included as a property under the signature node. Include the dtsi file in the dtb. This brings the embedding of the ESL in the dtb into the U-Boot build flow. The path to the ESL file is specified through the CONFIG_EFI_CAPSULE_ESL_FILE symbol. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2023-08-22 17:40:05 +00:00
config EFI_CAPSULE_ESL_FILE
string "Path to the EFI Signature List File"
depends on EFI_CAPSULE_AUTHENTICATE
help
Provides the path to the EFI Signature List file which will
be embedded in the platform's device tree and used for
capsule authentication at the time of capsule update.
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
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: disable GRUB_ARM32_WORKAROUND on ARCH_SUNXI GRUB_ARM32_WORKAROUND can be disabled on ARCH_SUNXI as the Allwinner SoCs only have a level 2 cache controlled via CP15 and not an architecturally defined cache. Having the cache available speeds up booting Linux. On ARCH_BCM283X it is already disabled via rpi_2_defconfig. But let's move this setting to Kconfig. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-03-03 13:05:05 +00:00
default n if ARCH_BCM283X || ARCH_SUNXI || 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"
efi_loader: Fix Kconfig for EFI_TCG2 protocol EFI_TCG2 depends not only on TPMv2 but also on the underlying algorithms. So select the missing SHA1, SHA256, SHA384 and SHA512 we currently support Reported-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Add 'default y'. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-05-11 11:40:58 +00:00
default y
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
depends on TPM_V2
efi_loader: Fix Kconfig for EFI_TCG2 protocol EFI_TCG2 depends not only on TPMv2 but also on the underlying algorithms. So select the missing SHA1, SHA256, SHA384 and SHA512 we currently support Reported-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Add 'default y'. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-05-11 11:40:58 +00:00
select SHA1
select SHA256
select SHA384
select SHA512
efi_loader: add PE/COFF image measurement "TCG PC Client Platform Firmware Profile Specification" requires to measure every attempt to load and execute a OS Loader(a UEFI application) into PCR[4]. This commit adds the PE/COFF image measurement, extends PCR, and appends measurement into Event Log. Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Replace CONFIG_HASH_CALCULATE by CONFIG_HASH Fix conversions between pointers and u64. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2021-05-26 03:09:58 +00:00
select HASH
efi_loader: add SMBIOS table measurement TCG PC Client Platform Firmware Profile Specification requires to measure the SMBIOS table that contains static configuration information (e.g. Platform Manufacturer Enterprise Number assigned by IANA, platform model number, Vendor and Device IDs for each SMBIOS table). The device- and environment-dependent information such as serial number is cleared to zero or space character for the measurement. Existing smbios_string() function returns pointer to the string with const qualifier, but exisintg use case is updating version string and const qualifier must be removed. This commit removes const qualifier from smbios_string() return value and reuses to clear the strings for the measurement. This commit also fixes the following compiler warning: lib/smbios-parser.c:59:39: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] const struct smbios_header *header = (struct smbios_header *)entry->struct_table_address; Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
2021-10-26 08:27:24 +00:00
select SMBIOS_PARSER
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
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
efi_loader: increase eventlog buffer size TCG PC Client PFP spec says "The Log Area Minimum Length for the TCG event log MUST be at least 64KB." in ACPI chapter. This commit increase the buffer size to 64KB. Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-07-14 13:00:01 +00:00
default 65536
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
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: Measure the loaded DTB Measures the DTB passed to the EFI application upon new boolean config switch CONFIG_EFI_TCG2_PROTOCOL_MEASURE_DTB. For platforms where the content of the DTB passed to the OS can change across reboots, there is not point measuring it hence the config switch to allow platform to not embed this feature. Co-developed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org> Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2023-02-16 16:29:48 +00:00
config EFI_TCG2_PROTOCOL_MEASURE_DTB
bool "Measure DTB with EFI_TCG2_PROTOCOL"
depends on EFI_TCG2_PROTOCOL
help
When enabled, the DTB image passed to the booted EFI image is
measured using the EFI TCG2 protocol. Do not enable this feature if
the passed DTB contains data that change across platform reboots
and cannot be used has a predictable measurement. Otherwise
this feature allows better measurement of the system boot
sequence.
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"
efi_loader: Replace config option for initrd loading Up to now we install EFI_LOAD_FILE2_PROTOCOL to load an initrd unconditionally. Although we correctly return various EFI exit codes depending on the file status (i.e EFI_NO_MEDIA, EFI_NOT_FOUND etc), the kernel loader, only falls back to the cmdline interpreted initrd if the protocol is not installed. This creates a problem for EFI installers, since they won't be able to load their own initrd and continue the installation. It also makes the feature hard to use, since we can either have a single initrd or we have to recompile u-boot if the filename changes. So let's introduce a different logic that will decouple the initrd path from the config option we currently have. When defining a UEFI BootXXXX we can use the filepathlist and store a file path pointing to our initrd. Specifically the EFI spec describes: "The first element of the array is a device path that describes the device and location of the Image for this load option. Other device paths may optionally exist in the FilePathList, but their usage is OSV specific" When the EFI application is launched through the bootmgr, we'll try to interpret the extra device path. If that points to a file that exists on our disk, we'll now install the load_file2 and the efi-stub will be able to use it. This opens up another path using U-Boot and defines a new boot flow. A user will be able to control the kernel/initrd pairs without explicit cmdline args or GRUB. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-03-17 19:55:00 +00:00
default y
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
help
efi_loader: Replace config option for initrd loading Up to now we install EFI_LOAD_FILE2_PROTOCOL to load an initrd unconditionally. Although we correctly return various EFI exit codes depending on the file status (i.e EFI_NO_MEDIA, EFI_NOT_FOUND etc), the kernel loader, only falls back to the cmdline interpreted initrd if the protocol is not installed. This creates a problem for EFI installers, since they won't be able to load their own initrd and continue the installation. It also makes the feature hard to use, since we can either have a single initrd or we have to recompile u-boot if the filename changes. So let's introduce a different logic that will decouple the initrd path from the config option we currently have. When defining a UEFI BootXXXX we can use the filepathlist and store a file path pointing to our initrd. Specifically the EFI spec describes: "The first element of the array is a device path that describes the device and location of the Image for this load option. Other device paths may optionally exist in the FilePathList, but their usage is OSV specific" When the EFI application is launched through the bootmgr, we'll try to interpret the extra device path. If that points to a file that exists on our disk, we'll now install the load_file2 and the efi-stub will be able to use it. This opens up another path using U-Boot and defines a new boot flow. A user will be able to control the kernel/initrd pairs without explicit cmdline args or GRUB. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-03-17 19:55:00 +00:00
Linux v5.7 and later can make use of this option. If the boot option
selected by the UEFI boot manager specifies an existing file to be used
as initial RAM disk, a Linux specific Load File2 protocol will be
installed and Linux 5.7+ will ignore any initrd=<ramdisk> command line
argument.
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
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"
efi: Correct dependency on FIT_SIGNATURE At present EFI_SECURE BOOT selects RSA but does not necessarily enable FIT_SIGNATURE. Mostly this is fine, but a few boards do not enable it, so U-Boot tries to do RSA verification when loading FIT images, but it is not enabled. This worked because the condition for checking the RSA signature is wrong in the fit_image_verify_with_data() function. In order to fix it we need to fix this dependency. Make sure that FIT_SIGNATURE is enabled so that RSA can be used. It might be better to avoid using 'select' in this situation. Signed-off-by: Simon Glass <sjg@chromium.org>
2021-09-26 01:43:29 +00:00
depends on EFI_LOADER && FIT_SIGNATURE
efi_loader: Work-around build issue due to missing hash_calculate() The hash_calculate() symbol is provided by hash-checksum.c. It depends on hash_progressive_lookup_algo(), provided when CONFIG_HASH=y. The issue is that hash_calculate() is used by the efi_loader, irregardless of CONFIG_FIT_SIGNATURE. As pointed out in commit 87316da05f2f ("lib: introduce HASH_CALCULATE option"), enabling hash_calculate() based on CONFIG_FIT_SIGNATURE is incorrect. To resolve this, use CONFIG_HASH as the compile switch for hash-checksum.c. This ensures that all dependencies are compiled, and is the most natural Kconfig to use. There is the issue of having to 'select HASH' in a couple of places that already 'select SHA256'. This is a deeper problem with how hashes are organized, and fixing it is beyonf the scope of this change. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Acked-by: Masahisa Kojima <masahisa.kojima@linaro.org>
2021-05-24 19:28:57 +00:00
select HASH
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
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: image_loader: add a missing digest verification for signed PE image At the last step of PE image authentication, an image's hash value must be compared with a message digest stored as the content (of SpcPeImageData type) of pkcs7's contentInfo. Fixes: commit 4540dabdcaca ("efi_loader: image_loader: support image authentication") Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
2022-07-05 05:48:14 +00:00
select MSCODE_PARSER
efi_loader: expose efi_image_parse() even if UEFI Secure Boot is disabled This is preparation for PE/COFF measurement support. PE/COFF image hash calculation is same in both UEFI Secure Boot image verification and measurement in measured boot. PE/COFF image parsing functions are gathered into efi_image_loader.c, and exposed even if UEFI Secure Boot is not enabled. This commit also adds the EFI_SIGNATURE_SUPPORT option to decide if efi_signature.c shall be compiled. Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-05-14 00:53:36 +00:00
select EFI_SIGNATURE_SUPPORT
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
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: expose efi_image_parse() even if UEFI Secure Boot is disabled This is preparation for PE/COFF measurement support. PE/COFF image hash calculation is same in both UEFI Secure Boot image verification and measurement in measured boot. PE/COFF image parsing functions are gathered into efi_image_loader.c, and exposed even if UEFI Secure Boot is not enabled. This commit also adds the EFI_SIGNATURE_SUPPORT option to decide if efi_signature.c shall be compiled. Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-05-14 00:53:36 +00:00
config EFI_SIGNATURE_SUPPORT
bool
efi: Add ESRT to the EFI system table The ESRT is initialised during efi_init_objlist after efi_initialize_system_table(). The ESRT is recreated from scratch at the following events: - successful UpdateCapsule; - FMP instance install. The code ensures that every ESRT entry has a unique fw_class value. Limitations: - The ESRT is not updated if an FMP instance is uninstalled; - the fields image_type and flags are in the current implementation left undefined. Setting these values will require a per-platform function that returns the image_type/flags as a function of the image fw_class. CC: Heinrich Schuchardt <xypron.glpk@gmx.de> CC: Sughosh Ganu <sughosh.ganu@linaro.org> CC: AKASHI Takahiro <takahiro.akashi@linaro.org> CC: Ilias Apalodimas <ilias.apalodimas@linaro.org> CC: Andre Przywara <andre.przywara@arm.com> CC: Alexander Graf <agraf@csgraf.de> CC: nd@arm.com Signed-off-by: Jose Marinho <jose.marinho@arm.com> Remove two EFI_CALL() indirections. Move ESRT GUID in efidebug's list of GUIDs. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
2021-03-02 17:26:38 +00:00
config EFI_ESRT
bool "Enable the UEFI ESRT generation"
depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
default y
help
Enabling this option creates the ESRT UEFI system table.
efi: Create ECPT table The ECPT table will be included in the UEFI specification 2.9+. The ECPT table was introduced in UEFI following the code-first path. The acceptance ticket can be viewed at: https://bugzilla.tianocore.org/show_bug.cgi?id=3591 The Conformance Profiles table is a UEFI configuration table that contains GUID of the UEFI profiles that the UEFI implementation conforms with. The ECPT table is created when CONFIG_EFI_ECPT=y. The config is set by default. Signed-off-by: Jose Marinho <jose.marinho@arm.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-12-23 14:51:07 +00:00
config EFI_ECPT
bool "Enable the UEFI ECPT generation"
default y
help
Enabling this option created the ECPT UEFI table.
efi: adjust ebbr to v2.1 in conformance profile The EFI Conformance Profile Table entry for EBBR appears in v2.1.0 of the EBBR specification[1]. Update naming accordingly. While at it, update the EBBR version referenced in the documentation. [1]: https://github.com/ARM-software/ebbr/releases/tag/v2.1.0 Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-12-16 16:55:04 +00:00
config EFI_EBBR_2_1_CONFORMANCE
bool "Add the EBBRv2.1 conformance entry to the ECPT table"
efi: ECPT add EBBRv2.0 conformance profile Display the EBBRv2.0 conformance in the ECPT table. The EBBRv2.0 conformance profile is set in the ECPT if CONFIG_EFI_EBBR_2_0_CONFORMANCE=y. Signed-off-by: Jose Marinho <jose.marinho@arm.com> Add dependencies for CONFIG_EFI_EBBR_2_0_CONFORMANCE. Enable the setting by default. Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-12-17 12:55:05 +00:00
depends on EFI_ECPT
depends on EFI_LOADER_HII
depends on EFI_RISCV_BOOT_PROTOCOL || !RISCV
depends on EFI_RNG_PROTOCOL || !DM_RNG
depends on EFI_UNICODE_COLLATION_PROTOCOL2
default y
help
efi: adjust ebbr to v2.1 in conformance profile The EFI Conformance Profile Table entry for EBBR appears in v2.1.0 of the EBBR specification[1]. Update naming accordingly. While at it, update the EBBR version referenced in the documentation. [1]: https://github.com/ARM-software/ebbr/releases/tag/v2.1.0 Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-12-16 16:55:04 +00:00
Enabling this option adds the EBBRv2.1 conformance entry to the ECPT UEFI table.
efi: ECPT add EBBRv2.0 conformance profile Display the EBBRv2.0 conformance in the ECPT table. The EBBRv2.0 conformance profile is set in the ECPT if CONFIG_EFI_EBBR_2_0_CONFORMANCE=y. Signed-off-by: Jose Marinho <jose.marinho@arm.com> Add dependencies for CONFIG_EFI_EBBR_2_0_CONFORMANCE. Enable the setting by default. Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2021-12-17 12:55:05 +00:00
efi_loader: Enable RISCV_EFI_BOOT_PROTOCOL support This adds support for new RISCV_EFI_BOOT_PROTOCOL to communicate the boot hart ID to bootloader/kernel on RISC-V UEFI platforms. The specification of the protocol is hosted at: https://github.com/riscv-non-isa/riscv-uefi Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
2022-01-28 15:18:44 +00:00
config EFI_RISCV_BOOT_PROTOCOL
bool "RISCV_EFI_BOOT_PROTOCOL support"
default y
depends on RISCV
help
The EFI_RISCV_BOOT_PROTOCOL is used to transfer the boot hart ID
to the next boot stage. It should be enabled as it is meant to
replace the transfer via the device-tree. The latter is not
possible on systems using ACPI.
efi_loader: support boot from URI device path This supports to boot from the URI device path. When user selects the URI device path, bootmgr downloads the file using wget into the address specified by loadaddr env variable. If the file is .iso or .img file, mount the image with blkmap then try to boot with the default file(e.g. EFI/BOOT/BOOTAA64.EFI). Since boot option indicating the default file is automatically created when new disk is detected, system can boot by selecting the automatically created blkmap boot option. If the file is PE-COFF file, load and start the downloaded file. The buffer used to download the ISO image file must be reserved to avoid the unintended access to the image and expose the ramdisk to the OS. For PE-COFF file case, this memory reservation is done in LoadImage Boot Service. [Ilias fix a few memory leaks by replacing returns with gotos] Lore: https://lore.kernel.org/u-boot/20231110042542.3797301-1-masahisa.kojima@linaro.org/T/#mbac31da301ff465b60894b38f3a587b2868cf817 Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
2023-11-10 04:25:40 +00:00
config EFI_HTTP_BOOT
bool "EFI HTTP Boot support"
select CMD_DNS
select CMD_WGET
select BLKMAP
help
Enabling this option adds EFI HTTP Boot support. It allows to
directly boot from network.
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