u-boot.git/lib/efi_loader/Kconfig, branch v2021.10

Revert "efi_capsule: Move signature from DTB to .rodata"

2021-09-18T09:47:50Z

This was unfortunately applied despite much discussion about it beiong the wrong way to implement this feature. Revert it before too many other things are built on top of it. This reverts commit ddf67daac39de76d2697d587148f4c2cb768f492. Signed-off-by: Simon Glass

Merge tag 'efi-2021-10-rc4-2' of https://source.denx.de/u-boot/custodians/u-boot-efi

2021-09-13T00:33:21Z

Pull request for efi-2021-10-rc4-2 Documentation: * improve documentation of U-Boot for /config DT node * integrate bloblist documentation UEFI: * correct usage of EFI_CALL() * code tidy up

efi_loader: require CONFIG_BLK

2021-09-11T09:02:02Z

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

Kconfig: Drop duplicate 'select SHA512' instances

2021-09-09T15:11:33Z

When dropping SHA512_ALGO in general, we didn't catch some cases where an option was selecting both SHA512 and SHA512_ALGO and caused them to select SHA512 twice. Kconfig doesn't complain, but this is still wrong and should be corrected. Fixes: e60e44993120 ("lib: Drop SHA512_ALGO in lieu of SHA512") Reported-by: Andreas Schwab Reviewed-by: Alexandru Gagniuc Signed-off-by: Tom Rini

lib: Drop SHA512_ALGO in lieu of SHA512

2021-09-08T20:11:46Z

SHA512_ALGO was used as a "either SHA512 or SHA384", although the implementations of these two algorithms share a majority of code. From a Kconfig interface perspective, it makes sense to present two distinct options. This requires #ifdefing out the SHA512 implementation from sha512.c. The latter doesn't make any sense. It's reasonable to say in Kconfig that SHA384 depends on SHA512, and seems to be the more polite way to handle the selection. Thus, automatically select SHA512 when SHA384 is enabled. Signed-off-by: Alexandru Gagniuc

efi_capsule: Move signature from DTB to .rodata

2021-07-18T12:43:56Z

The capsule signature is now part of our DTB. This is problematic when a user is allowed to change/fixup that DTB from U-Boots command line since he can overwrite the signature as well. So Instead of adding the key on the DTB, embed it in the u-boot binary it self as part of it's .rodata. This assumes that the U-Boot binary we load is authenticated by a previous boot stage loader. Reviewed-by: Masami Hiramatsu Tested-by: Masami Hiramatsu Tested-by: Sughosh Ganu Signed-off-by: Ilias Apalodimas

efi_loader: increase eventlog buffer size

2021-07-18T12:43:56Z

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 Reviewed-by: Heinrich Schuchardt

efi_loader: set partition GUID in device path for SIG_TYPE_GUID

2021-07-18T12:43:56Z

Previously, the GPT device GUID was being used instead of the partition, which was incorrect. Signed-off-by: Alfonso Sánchez-Beato Let EFI_LOADER select CONFIG_PARTITION_UUIDS. Use log_warning() instead of printf() for warning. Reviewed-by: Heinrich Schuchardt

efi_loader: Allow capsule update on-disk without checking OsIndications

2021-07-02T16:29:06Z

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 Reword Kconfig description. Reviewed-by: Heinrich Schuchardt Signed-off-by: Heinrich Schuchardt

efi_loader: Force a single FMP instance per hardware store

2021-07-02T07:37:01Z

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 Reviewed-by: Heinrich Schuchardt