In the prior commits, interfaces for executing EFI binary and boot manager
were carved out. Move them under efi_loader directory so that they can
be called from other places without depending on bootefi command.
Only efi_selftest-related code will be left in bootefi.c.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
commit 239d59a65e ("efi_loader: reconnect drivers on failure")
tried to fix the UninstallProtocol interface which must reconnect
any controllers it disconnected by calling ConnectController()
in case of failure. However, the reconnect functionality was wired in
efi_disconnect_all_drivers() instead of efi_uninstall_protocol().
As a result some SCT tests started failing.
Specifically, BBTestOpenProtocolInterfaceTest333CheckPoint3() test
- Calls ConnectController for DriverImageHandle1
- Calls DisconnectController for DriverImageHandle1 which will
disconnect everything apart from TestProtocol4. That will remain
open on purpose.
- Calls ConnectController for DriverImageHandle2. TestProtocol4
which was explicitly preserved was installed wth BY_DRIVER attributes.
The new protocol will call DisconnectController since its attributes
are BY_DRIVER|EXCLUSIVE, but TestProtocol4 will not be removed. The
test expects EFI_ACCESS_DENIED which works fine.
The problem is that DisconnectController, will eventually call
EFI_DRIVER_BINDING_PROTOCOL.Stop(). But on the aforementioned test
this will call CloseProtocol -- the binding protocol is defined in
'DBindingDriver3.c' and the .Stop function uses CloseProtocol.
If that close protocol call fails with EFI_NOT_FOUND, the current code
will try to mistakenly reconnect all drivers and the subsequent tests
that rely on the device being disconnected will fail.
Move the reconnection in efi_uninstall_protocol() were it belongs.
Fixes: commit 239d59a65e ("efi_loader: reconnect drivers on failure")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
ACPI tables cannot convey memory reservations for ARM and RISC-V.
x86 uses the BIOS E820 table for this purpose. We cannot simply ignore the
device-tree when booting via ACPI. We have to assign EfiReservedMemory
according to the prior stage device-tree ($fdtaddr) or as fallback the
control device-tree ($fdtcontroladdr).
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
We currently use an outdated format 32-bit format for SMBIOS tables.
So we must allocate SMBIOS tables below 4 GiB.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
It is unclear to developers why efi_var_from_file() returns EFI_SUCCESS if
file ubootefi.var is missing or corrupted. Improve the description.
Reported-by: Weizhao Ouyang <o451686892@gmail.com>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Weizhao Ouyang <o451686892@gmail.com>
The result of efi_append_scrtm_version() is overwritten before anyone
checks its result. Check it and exit the function on failures
Addresses-Coverity-ID: 467399 Code maintainability issues (UNUSED_VALUE)
Fixes: commit 97707f12fd ("tpm: Support boot measurements")
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
In commit 9fd3f881c6 ("efi_loader: Increase default variable store size to 64KiB")
Alper has a detailed explanation of why the size needs to be bumped to at
least 64K. However enabling Secure boot, writing db, KEK, PK etc keys
will further increase the size so bump it to 128K.
It's worth noting that when U-Boot stores the EFI variables in an RPMB the
available storage is defined statically in StandAloneMM at build time.
The U-Boot code is detecting the available true size on the fly during
writes. When StandAloneMM is present this size defines the reserved
memory U-Boot can use to copy any runtime variables, before booting an
OS.
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
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>
When the image loaded by efibootmgr returns, efibootmgr
needs to clean the resources. Adding the event of returning
to efibootmgr is useful to simplify the implementation.
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>
const classifier is missing in EventGroup parameter of
CreateEventEx(). Fix it to remove the compiler warning.
NotifyContext parameter of CreateEventEx() is also defined
with const in UEFI specification, but NotifyContext parameter
of CreateEvent() is defined without const.
Since current implementation calls the common efi_create_event()
function from both CreateEventEx() and CreateEvent() services,
NotifyContext parameter leaves as is.
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>
Changes for complying to EFI spec §3.5.1.1
'Removable Media Boot Behavior'.
Boot variables can be automatically generated during a removable
media is probed. At the same time, unused boot variables will be
detected and removed.
Please note that currently the function 'efi_disk_remove' has no
ability to distinguish below two scenarios
a) Unplugging of a removable media under U-Boot
b) U-Boot exiting and booting an OS
Thus currently the boot variables management is not added into
'efi_disk_remove' to avoid boot options being added/erased
repeatedly under scenario b) during power cycles
See TODO comments under function 'efi_disk_remove' for more details
The original efi_secboot tests expect that BootOrder EFI variable
is not defined. With this commit, the BootOrder EFI variable is
automatically added when the disk is detected. The original
efi_secboot tests end up with unexpected failure.
The efi_secboot tests need to be modified to explicitly set
the BootOrder EFI variable.
squashfs and erofs ls tests are also affected by this modification,
need to clear the previous state before squashfs ls test starts.
Co-developed-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
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>
Reviewed-by: Joao Marcos Costa <jmcosta944@gmail.com>
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
The efi_gop driver uses private fields from the video uclass to obtain a
pointer to the frame buffer. Use the platform data instead.
Check the VIDEO_COPY setting to determine which frame buffer to use. Once
the next stage is running (and making use of U-Boot's EFI boot services)
U-Boot does not handle copying from priv->fb to the hardware framebuffer,
so we must allow EFI to write directly to the hardware framebuffer.
We could provide a function to read this, but it seems better to just
document how it works. The original change ignored an explicit comment
in the video.h file ("Things that are private to the uclass: don't use
these in the driver") which is why this was missed when the VIDEO_COPY
feature was added.
Signed-off-by: Simon Glass <sjg@chromium.org>
Fixes: 8f661a5b66 ("efi_loader: gop: Expose fb when 32bpp")
Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
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>
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>
