efi_tcg2_get_active_pcr_banks doesn't immediately call the
EFI_ENTRY() wrapper once it enters the function. Move the call a
few lines above to cover the error cases properly as well.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add TPM2 functions to support boot measurement. This includes
starting up the TPM, initializing/appending the event log, and
measuring the U-Boot version. Much of the code was used in the
EFI subsystem, so remove it there and use the common functions.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
For the API moving around from EFI -> u-boot core
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
For EFI testing
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The driver needs to support getting the PCRs in the capabilities
command. Fix various other things and support the max number
of PCRs for TPM2.
Remove the !SANDBOX dependency for EFI TCG2 as well.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
U-Boot should set up the SMBIOS tables during startup, as it does on x86.
Ensure that it does this correctly on non-x86 machines too, by creating
an event spy for last-stage init.
Tidy up the installation-condition code while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
It is not always the case that U-Boot builds the ACPI tables itself. For
example, when booting from coreboot, the ACPI tables are built by
coreboot.
Correct the Makefile condition so that U-Boot can pass on tables built
by a previous firmware stage.
Tidy up the installation-condition code while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
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>
When a notification event is registered for a protocol the handle of the
protocol is added in our event notification list. When all the protocols
of the handle are uninstalled we delete the handle but we do not remove
it from the event notification list.
Clean up the protocol removal functions and add a wrapper which
- Removes the to-be deleted handle from any lists it participates
- Remove the handle if no more protocols are present
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
In efi_add_known_memory() we currently call board_get_usable_ram_top() with
an incorrect value 0 of parameter total_size. This leads to an incorrect
value for ram_top depending on the code in board_get_usable_ram_top().
Use the value of gd->ram_top instead which is set before relocation by
calling board_get_usable_ram_top().
Fixes: 7b78d6438a ("efi_loader: Reserve unaccessible memory")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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>
Check the uuid_str_to_bin return value, skip the node
if the image-type-id property is wrong format.
Addresses-Coverity-ID: 463145 ("Error handling issues")
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* If an error occurs in efi_disk_add_dev(), don't leak resources.
* If calloc() fails while creating the file system protocol interface,
signal an error.
* Rename efi_simple_file_system() to efi_create_simple_file_system().
* Drop a little helpful debug message.
Fixes: 2a92080d8c ("efi_loader: add file/filesys support")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Handle out of memory situation in efi_mem_carve_out().
Fixes: 5d00995c36 ("efi_loader: Implement memory allocation and map")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
On 32bit systems (pages << EFI_PAGE_SHIFT) may lead to an overflow which
does not occur in 64bit arithmetics.
An overflow of (pages << EFI_PAGE_SHIFT) on 64bit systems should be treated
as an error.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
If the hard coded array hash_algo_list[] contains an entry for an
unsupported algorithm, we should not leak resources new_efi and regs.
We should still extend the log with the digests for the supported
algorithms and not write any message.
The same holds true of tcg2_create_digest(): just continue in case
hash_algo_list[] contains an unsupported entry.
Fixes: 163a0d7e2c ("efi_loader: add PE/COFF image measurement")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Handle out of memory situation in efi_add_memory_map_pg().
Fixes: 5d00995c36 ("efi_loader: Implement memory allocation and map")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The efi_parse_pkcs7_header() function returns NULL on error so the check
for IS_ERR() should be changed to a NULL check.
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
While UPDATE_CAPSULE api is not fully implemented, this interface and
capsule-on-disk feature should behave in the same way, especially in
handling an empty capsule for fwu multibank, for future enhancement.
So move the guid check into efi_capsule_update_firmware().
Fixed: commit a6aafce494 ("efi_loader: use efi_update_capsule_firmware() for capsule on disk")
Reported-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reported-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Tested-by: Michal Simek <michal.simek@amd.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
It's pretty unlikely that anyone is going to be using EFI authentication
on a 32bit system. However, if you did, the efi_prepare_aligned_image()
function would write 8 bytes of data to the &efi_size variable and it
can only hold 4 bytes so that corrupts memory.
Fixes: 163a0d7e2c ("efi_loader: add PE/COFF image measurement")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The EFI doesn't allow removal of handles, unless all hosted protocols
are cleanly removed. Our efi_delete_handle() is a bit intrusive.
Although it does try to delete protocols before removing a handle,
it doesn't care if that fails. Instead it only returns an error if the
handle is invalid. On top of that none of the callers of that function
check the return code.
So let's rewrite this in a way that fits the EFI spec better. Instead
of forcing the handle removal, gracefully uninstall all the handle
protocols. According to the EFI spec when the last protocol is removed
the handle will be deleted. Also switch all the callers and check the
return code. Some callers can't do anything useful apart from reporting
an error. The disk related functions on the other hand, can prevent a
medium that is being used by EFI from removal.
The only function that doesn't check the result is efi_delete_image().
But that function needs a bigger rework anyway, so we can clean it up in
the future
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Move the recursive dp_fill(dev->parent) call to a single location.
Determine uclass_id only once.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The UEFI specification does not provide node types matching UCLASS_BLKMAP,
UCLASS_HOST, UCLASS_VIRTIO block devices.
The current implementation uses VenHw() nodes with uclass specific GUIDs
and a single byte for the device number appended. This leads to unaligned
integers in succeeding device path nodes.
The current implementation fails to create unique device paths for block
devices based on other uclasses like UCLASS_PVBLOCK.
Let's use a VenHw() node with the U-Boot GUID with a length dividable by
four and encoding blkdesc->uclass_id as well as blkdesc->devnum.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This reverts commit d927d1a808, reversing
changes made to c07ad9520c.
These changes do not pass CI currently.
Signed-off-by: Tom Rini <trini@konsulko.com>
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.
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>
On devices with multiple USB mass storage devices errors like
Path /../USB(0x0,0x0)/USB(0x1,0x0)/Ctrl(0x0)
already installed.
are seen. This is due to creating non-unique device paths. To uniquely
identify devices we must provide path nodes for all devices on the path
from the root device.
Add support for generating device path nodes for all uclasses.
Reported-by: Suniel Mahesh <sunil@amarulasolutions.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Do not assume that the preceding device path contains a single VenHW node.
Instead use the return value of dp_fill() which provides the address of the
next node.
Fixes: 23ad52fff4 ("efi_loader: device_path: support Sandbox's "host" devices")
Fixes: 19ecced71c ("efi_loader: device path for virtio block devices")
Fixes: 272ec6b453 ("efi_loader: device_path: support blkmap devices")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
A previous patch is removing the last consumer of efi_remove_protocol().
Switch that to static and treat it as an internal API in order to force
users install and remove protocols with the appropriate EFI functions.
It's worth noting that we still have files using efi_add_protocol(). We
should convert all these to efi_install_multiple_protocol_interfaces()
and treat efi_add_protocol() in a similar manner
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The TCG2 protocol currently adds and removes protocols with
efi_(add/remove)_protocol().
Removing protocols with efi_remove_protocol() might prove
problematic since it doesn't call DisconnectController() when
uninstalling the protocol and does not comply with the UEFI specification.
It's also beneficial for readability to have protocol installations and
removals in pairs -- IOW when efi_install_multiple_protocol_interfaces()
is called, efi_uninstall_multiple_protocol_interfaces() should be used to
remove it. So let's swap the efi_add_protocol() as well.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The call to efi_search_obj() is redundant as the function is called in
efi_search_protocol() too.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
U-Boot sets up the ACPI tables during startup. Rather than creating a
new set, install the existing ones. Create a memory-map record to cover
the tables.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Up to now we did not check the return value of DisconnectController.
A previous patch is fixing that taking into account what happened during
the controller disconnect. But that check takes place before our code
is trying to figure out if the interface exists to begin with. In case a
driver is not allowed to unbind -- e.g returning EFI_DEVICE_ERROR, we
will end up returning that error instead of EFI_NOT_FOUND.
Add an extra check on the top of the function to make sure the protocol
interface exists before trying to disconnect any drivers
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
efi_uninstall_protocol() calls efi_disconnect_all_drivers() but never
checks the return value. Instead it tries to identify protocols that
are still open after closing the ones that were opened with
EFI_OPEN_PROTOCOL_BY_HANDLE_PROTOCOL, EFI_OPEN_PROTOCOL_GET_PROTOCOL
and EFI_OPEN_PROTOCOL_TEST_PROTOCOL.
Instead of doing that, check the return value early and exit if
disconnecting the drivers failed. Also reconnect all the drivers of
a handle if protocols are still found on the handle after disconnecting
controllers and closing the remaining protocols.
While at it fix a memory leak and properly free the opened protocol
information when closing a protocol.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
efi_disconnect_controller() doesn't reconnect drivers in case of
failure. Reconnect the disconnected drivers properly
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The boot variables automatically generated for removable medias
should be with short form of device path without device nodes.
This is a requirement for the case that a removable media is
plugged into a different port but is still able to work with the
existing boot variables.
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Correct the return code for out-of-memory and no boot option found
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Rename and move bootorder and bootoption apis from cmd to lib
for re-use between eficonfig and bootmgr
Fix 'unexpected indentation' when 'make htmldocs' after functions
are moved
Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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>
The efi_var_mem_free() function calculates the available size for a new
EFI variable by subtracting the occupied buffer size and the overhead
for a new variable from the maximum buffer size set in Kconfig. This
is then returned as QueryVariableInfo()'s RemainingVariableStorageSize
output.
This can underflow as the calculation is done in and processed as
unsigned integer types. Check for underflow before doing the subtraction
and return zero if there's no space.
Fixes: f1f990a8c9 ("efi_loader: memory buffer for variables")
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Instead of discovering the ID of the device and call two different
functions for a block device or a partition, we can rewrite
efi_disk_remove() and handle the minor differences between the two
variants internally. As a results we can simplify efi_disk_remove()
a lot and get rid of the extra efi_disk_delete_raw/blk calls.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
If a handle is not found, return 0 to let the device be removed.
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The FMP Payload Header which EDK II capsule generation scripts
insert has a firmware version.
This commit reads the lowest supported version stored in the
device tree, then check if the firmware version in FMP payload header
of the ongoing capsule is equal or greater than the
lowest supported version. If the firmware version is lower than
lowest supported version, capsule update will not be performed.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
This commit gets the lowest supported version from device tree,
then fills the lowest supported version in FMP->GetImageInfo().
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Current FMP->GetImageInfo() always return 0 for the firmware
version, user can not identify which firmware version is currently
running through the EFI interface.
This commit reads the "FmpStateXXXX" EFI variable, then fills the
firmware version in FMP->GetImageInfo().
Now FMP->GetImageInfo() and ESRT have the meaningful version number.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Firmware version management is not implemented in the current
FMP protocol.
EDK II reference implementation capsule generation script inserts
the FMP Payload Header right before the payload, FMP Payload Header
contains the firmware version and lowest supported version.
This commit utilizes the FMP Payload Header, reads the header and
stores the firmware version into "FmpStateXXXX" EFI non-volatile variable.
XXXX indicates the image index, since FMP protocol handles multiple
image indexes.
Note that lowest supported version included in the FMP Payload Header
is not used. If the platform uses file-based EFI variable storage,
it can be tampered. The file-based EFI variable storage is not the
right place to store the lowest supported version for anti-rollback
protection.
This change is compatible with the existing FMP implementation.
This change does not mandate the FMP Payload Header.
If no FMP Payload Header is found in the capsule file, fw_version,
lowest supported version, last attempt version and last attempt
status is 0 and this is the same behavior as existing FMP
implementation.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
