u-boot.git/lib/efi_loader/efi_setup.c, branch v2021.07

efi_loader: clear OsIndications

2021-07-02T07:37:01+00:00

After each reboot we must clear flag
EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED in variable
OsIndications.

Signed-off-by: Heinrich Schuchardt

efi_loader: Always install FMPs

2021-07-02T07:37:01+00:00

We only install FMPs if a CapsuleUpdate is requested.  Since we now have an
ESRT table which relies on FMPs to build the required information, it
makes more sense to unconditionally install them. This will allow userspace
applications (e.g fwupd) to make use of the ERST and provide us with files
we can use to run CapsuleUpdate on-disk

Signed-off-by: Ilias Apalodimas 
Reviewed-by: Heinrich Schuchardt

efi: Add ESRT to the EFI system table

2021-03-25T19:19:19+00:00

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	
CC: Sughosh Ganu 
CC: AKASHI Takahiro 
CC: Ilias Apalodimas 
CC: Andre Przywara 
CC: Alexander Graf 
CC: nd@arm.com
Signed-off-by: Jose Marinho 

Remove two EFI_CALL() indirections.
Move ESRT GUID in efidebug's list of GUIDs.

Reviewed-by: Heinrich Schuchardt

efi_loader: switch to non-secure mode later

2021-01-29T19:22:40+00:00

Some ARMv7 boards using PSCI require to be in secure-mode when booted via
'bootz' or 'bootm'. During distro-boot 'bootefi bootmgr' is called to check
if booting via UEFI is possible.

With the change we change the switch from secure mode to non-secure mode is
moved from the UEFI subsystem setup to just before calling StartImage().

Cc: Jernej Škrabec 
Reported by: Andre Przywara 
Signed-off-by: Heinrich Schuchardt

efi_loader: Remove unconditional installation of file2 protocol for initrd

2020-12-31T13:33:22+00:00

Up to now we install the 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 start the installation.

A following patch introduces a different logic where we search for an
initrd path defined in an EFI variable named 'Initrd####'.
If the bootmgr is used to launch the EFI payload, we'll will try to match
the BootCurrent value and find the corresponding initrd
(i.e Boot0000 -> Initrd0000 etc). If the file is found, we'll install
the required protocol which the kernel's efi-stub can use and load our
initrd.

Signed-off-by: Ilias Apalodimas 
Signed-off-by: Heinrich Schuchardt

efi_loader: capsule: support firmware update

2020-12-03T20:22:50+00:00

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

efi_loader: capsule: add capsule_on_disk support

2020-12-03T20:22:49+00:00

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

efi_loader: define UpdateCapsule api

2020-12-03T20:22:49+00:00

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

efi_loader: Introduce eventlog support for TCG2_PROTOCOL

2020-12-03T20:22:40+00:00

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

efi_loader: Add basic EFI_TCG2_PROTOCOL support

2020-11-14T04:05:46+00:00

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 
Acked-by: Heinrich Schuchardt 
Signed-off-by: Heinrich Schuchardt