u-boot.git/cmd/bootefi.c, branch v2022.10

efi_loader: memory leak in efi_set_bootdev()

2022-07-13T18:07:07+00:00

efi_dp_str() allocates memory which should be released after use.

Use %pD printf code. Adjust message wording.

Fixes: d837cb1e3b6b ("efi: Add debugging to efi_set_bootdev()")
Signed-off-by: Heinrich Schuchardt

cmd: load: add load command for memory mapped

2022-06-22T15:35:47+00:00

cp.b is used a lot as a way to load binaries to memory and execute
them, however we may need to integrate this with the efi subsystem to
set it up as a bootdev.

So, introduce a loadm command that will be consistent with the other
loadX commands and will call the efi API's.

ex: loadm $kernel_addr $kernel_addr_r $kernel_size

with this a kernel with CONFIG_EFI_STUB enabled will be loaded and
then subsequently booted with bootefi command.

Signed-off-by: Rui Miguel Silva 
Reviewed-by: Tom Rini

cmd/bootefi: correct command syntax

2022-05-28T08:59:27+00:00

For indicating the address and size of a memory region other commands use a
[:] syntax. Do the same for bootefi.

Fixes: 2058983689f0 ("cmd: bootefi: restore ability to boot arbitrary blob")
Signed-off-by: Heinrich Schuchardt

cmd: bootefi: restore ability to boot arbitrary blob

2022-04-23T20:05:33+00:00

Up until commit 5f59518a7b1ae ("efi_loader: setting boot device"), we
could boot an arbitrary blob with bootefi. Indeed, efi_run_image() even
has a special case for missing device paths indicating a payload that
was directly loaded via JTAG, for example.

Restore the ability to inject a UEFI payload into memory and `bootefi`
it. If the address passed isn't the last PE-COFF loaded, then we'll
wipe out the pre-existing DP/Image information and let efi_run_image()
synthesize a memory device path.

An image size is required if we're booting an arbitrary payload, and
the FDT argument has been changed to accept `-`. The size could be
deduced from the image header, but it's required anyways as an explicit
acknowledgment that one's trying to boot an arbitrary payload rather
than accidentally using the wrong address in the single-addr form.

Fixes: 5f59518a7b1a ("efi_loader: setting boot device")
Signed-off-by: Kyle Evans 
Reviewed-by: Heinrich Schuchardt

efi_loader: Ignore DT when ACPI is on

2022-03-20T10:03:06+00:00

For targets that enable ACPI, we should not pass Device Trees into
the payload. However, our distro boot logic always passes the builtin
DT as an argument.

To make it easy to use ACPI with distro boot, let's just ignore the DT
argument to bootefi when ACPI is enabled. That way, we can successfully
distro boot payloads on ACPI enabled targets.

Signed-off-by: Alexander Graf 
Reviewed-by: Mark Kettenis 
Reviewed-by: Heinrich Schuchardt

efi_loader: update the timing of enabling and disabling EFI watchdog

2022-02-26T06:37:01+00:00

UEFI specification requires that 5 minutes watchdog timer is
armed before the firmware's boot manager invokes an EFI boot option.
This watchdog timer is updated as follows, according to the
UEFI specification.

 1) The EFI Image may reset or disable the watchdog timer as needed.
 2) If control is returned to the firmware's boot manager,
    the watchdog timer must be disabled.
 3) On successful completion of EFI_BOOT_SERVICES.ExitBootServices()
    the watchdog timer is disabled.

1) is up to the EFI image, and 3) is already implemented in U-Boot.
This patch implements 2), the watchdog is disabled when control is
returned to U-Boot.

In addition, current implementation arms the EFI watchdog at only
the first "bootefi" invocation. The EFI watchdog must be armed
in every EFI boot option invocation.

Signed-off-by: Masahisa Kojima 
Reviewed-by: Heinrich Schuchardt

efi: Add debugging to efi_set_bootdev()

2022-02-05T19:20:01+00:00

The operation of this function can be confusing. Add some debugging so
we can see what it is doing and when it is called.

Also drop the preprocessor usage.

Signed-off-by: Simon Glass 
Reviewed-by: heinrich Schuchardt

efi_loader: Get rid of kaslr-seed if EFI_RNG_PROTOCOL is installed

2022-01-15T09:57:22+00:00

U-Boot, in some occasions, injects a 'kaslr-seed' property on the /chosen
node. That would be problematic in case we want to measure the DTB we
install in the configuration table, since it would change across reboots.

The Linux kernel EFI-stub completely ignores it and only relies on
EFI_RNG_PROTOCOL for it's own randomness needs (i.e the randomization
of the physical placement of the kernel). In fact it (blindly) overwrites
the existing seed if the protocol is installed. However it still uses it
for randomizing it's virtual placement.
So let's get rid of it in the presence of the RNG protocol.

It's worth noting that TPMs also provide an RNG.  So if we tweak our
EFI_RNG_PROTOCOL slightly and install the protocol when a TPM device
is present the 'kaslr-seed' property will always be removed, allowing
us to reliably measure our DTB.

Acked-by: Ard Biesheuvel 
Signed-off-by: Ilias Apalodimas 
Reviewed-by: Mark Kettenis

global: Convert simple_strtoul() with hex to hextoul()

2021-08-02T17:32:14+00:00

It is a pain to have to specify the value 16 in each call. Add a new
hextoul() function and update the code to use it.

Add a proper comment to simple_strtoul() while we are here.

Signed-off-by: Simon Glass

efi_loader: Replace config option for initrd loading

2021-03-25T19:14:26+00:00

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