u-boot.git/include/efi_api.h, branch v2020.07-rc4 Unnamed repository; edit this file 'description' to name the repository. efi_loader: device path for SATA devices 2020-05-21T08:00:17+00:00 Heinrich Schuchardt xypron.glpk@gmx.de 2020-05-20T21:12:02+00:00 bf3bcef7fb8ef4b0bb56d00304a934a5a5eb187e Provide device path nodes for SATA devices. This avoids creation of two handles with the same device path indicating our root node. This is what the device paths for a SATA drive with four partitions could like: /VenHw(..)/Sata(0x0,0xffff,0x0) /VenHw(..)/Sata(0x0,0xffff,0x0)/HD(1,MBR,0x81ea591f,0x800,0x63ff830) /VenHw(..)/Sata(0x0,0xffff,0x0)/HD(2,MBR,0x81ea591f,0x6400800,0x9ff830) /VenHw(..)/Sata(0x0,0xffff,0x0)/HD(3,MBR,0x81ea591f,0x6e00800,0x16ef2ab0) /VenHw(..)/Sata(0x0,0xffff,0x0)/HD(4,MBR,0x81ea591f,0x1dcf3800,0x1dcedab0) Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> 
Provide device path nodes for SATA devices.

This avoids creation of two handles with the same device path indicating
our root node.

This is what the device paths for a SATA drive with four partitions could
like:

/VenHw(..)/Sata(0x0,0xffff,0x0)
/VenHw(..)/Sata(0x0,0xffff,0x0)/HD(1,MBR,0x81ea591f,0x800,0x63ff830)
/VenHw(..)/Sata(0x0,0xffff,0x0)/HD(2,MBR,0x81ea591f,0x6400800,0x9ff830)
/VenHw(..)/Sata(0x0,0xffff,0x0)/HD(3,MBR,0x81ea591f,0x6e00800,0x16ef2ab0)
/VenHw(..)/Sata(0x0,0xffff,0x0)/HD(4,MBR,0x81ea591f,0x1dcf3800,0x1dcedab0)

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
efi_loader: add signature verification functions 2020-04-16T06:12:46+00:00 AKASHI Takahiro takahiro.akashi@linaro.org 2020-04-14T02:51:39+00:00 593e17d673abe8e903412e6d55b2eb54b159b096 In this commit, implemented are a couple of helper functions which will be used to materialize variable authentication as well as image authentication in later patches. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> 
In this commit, implemented are a couple of helper functions which will be
used to materialize variable authentication as well as image authentication
in later patches.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
efi_loader: definition of GetNextVariableName() 2020-03-22T17:38:02+00:00 Heinrich Schuchardt xypron.glpk@gmx.de 2020-03-22T17:28:20+00:00 7a4e717b9c0c255137a58f3ab90f002fc3aade2b 'vendor' is both an input and an output parameter. So it cannot be constant. Fixes: 0bda81bfdc5c ("efi_loader: use const efi_guid_t * for variable services") Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> 
'vendor' is both an input and an output parameter. So it cannot be
constant.

Fixes: 0bda81bfdc5c ("efi_loader: use const efi_guid_t * for variable services")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
efi_loader: correct a definition of struct efi_capsule_header 2020-03-17T07:29:52+00:00 AKASHI Takahiro takahiro.akashi@linaro.org 2020-03-17T02:12:37+00:00 74b44875357378c83e4bd150c0b759ca6ae6563a See UEFI specification, section 8.5.3. In addition, the structure, efi_capsule_header, should be "packed" as it is a serialized binary format in a capsule file. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> 
See UEFI specification, section 8.5.3.
In addition, the structure, efi_capsule_header, should be "packed"
as it is a serialized binary format in a capsule file.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
efi_loader: define System Resource Table macros 2020-03-17T07:29:52+00:00 AKASHI Takahiro takahiro.akashi@linaro.org 2020-03-17T02:12:35+00:00 b74d568d83689234f505726399e483d2dc509898 Some of those values will be used in an implementation of UEFI firmware management protocol as part of my capsule update patch. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> 
Some of those values will be used in an implementation of UEFI firmware
management protocol as part of my capsule update patch.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
efi_loader: define OsIndicationsSupported flags 2020-03-17T07:29:52+00:00 AKASHI Takahiro takahiro.akashi@linaro.org 2020-03-17T02:12:34+00:00 7cceef7bde3d78dbd0f85794fbda0c431bac39c0 These flags are expected to be set in OsIndicationsSupported variable if corresponding features are supported. See UEFI specification, section 8.5.4. In particular, capsule-related flags will be used in my capsule update patch. Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> Fix misspelled EFI_OS_INDICATIONS_BOOT_TO_FW_UI. Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> 
These flags are expected to be set in OsIndicationsSupported variable
if corresponding features are supported. See UEFI specification,
section 8.5.4.

In particular, capsule-related flags will be used in my capsule
update patch.

Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>

Fix misspelled EFI_OS_INDICATIONS_BOOT_TO_FW_UI.
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
efi_loader: Implement FileLoad2 for initramfs loading 2020-02-28T18:37:14+00:00 Ilias Apalodimas ilias.apalodimas@linaro.org 2020-02-21T07:55:45+00:00 ec80b4735a593961fe701cc3a5d717d4739b0fd0 Following kernel's proposal for an arch-agnostic initrd loading mechanism [1] let's implement the U-boot counterpart. This new approach has a number of advantages compared to what we did up to now. The file is loaded into memory only when requested limiting the area of TOCTOU attacks. Users will be allowed to place the initramfs file on any u-boot accessible partition instead of just the ESP one. Finally this is an attempt of a generic interface across architectures in the linux kernel so it makes sense to support that. The file location is intentionally only supported as a config option argument(CONFIG_EFI_INITRD_FILESPEC), in an effort to enhance security. Although U-boot is not responsible for verifying the integrity of the initramfs, we can enhance the offered security by only accepting a built-in option, which will be naturally verified by UEFI Secure Boot. This can easily change in the future if needed and configure that via ENV or UEFI variable. [1] https://lore.kernel.org/linux-efi/20200207202637.GA3464906@rani.riverdale.lan/T/#m4a25eb33112fab7a22faa0fd65d4d663209af32f Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> 
Following kernel's proposal for an arch-agnostic initrd loading
mechanism [1] let's implement the U-boot counterpart.
This new approach has a number of advantages compared to what we did up
to now. The file is loaded into memory only when requested limiting the
area of TOCTOU attacks. Users will be allowed to place the initramfs
file on any u-boot accessible partition instead of just the ESP one.
Finally this is an attempt of a generic interface across architectures
in the linux kernel so it makes sense to support that.

The file location is intentionally only supported as a config option
argument(CONFIG_EFI_INITRD_FILESPEC), in an effort to enhance security.
Although U-boot is not responsible for verifying the integrity of the
initramfs, we can enhance the offered security by only accepting a
built-in option, which will be naturally verified by UEFI Secure Boot.
This can easily change in the future if needed and configure that via ENV
or UEFI variable.

[1] https://lore.kernel.org/linux-efi/20200207202637.GA3464906@rani.riverdale.lan/T/#m4a25eb33112fab7a22faa0fd65d4d663209af32f

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
efi_loader: implement EFI_RT_PROPERTIES_TABLE 2020-02-26T18:32:09+00:00 Heinrich Schuchardt xypron.glpk@gmx.de 2020-02-19T19:48:49+00:00 76be687288dc618eabd1ef643488cd5bd93f84ff UEFI spec 2.8 errata A replaces the RuntimeServicesSupported variable defined in UEFI spec 2.8 by the configuration table EFI_RT_PROPERTIES_TABLE. So let's follow suit. Cc: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Tested-by: Ard Biesheuvel <ardb@kernel.org> 
UEFI spec 2.8 errata A replaces the RuntimeServicesSupported variable
defined in UEFI spec 2.8 by the configuration table
EFI_RT_PROPERTIES_TABLE. So let's follow suit.

Cc: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Tested-by: Ard Biesheuvel <ardb@kernel.org>
efi: device path for nvme 2019-10-06T14:02:37+00:00 Patrick Wildt patrick@blueri.se 2019-10-03T14:24:17+00:00 f2d247df506eaf984f26ec03baf115d70bd75b9c This allows our EFI API to create a device path node for NVMe devices. It adds the necessary device path struct, uses the nvme namespace accessor to retrieve the id and eui64, and also provides support for the device path text protocol. Signed-off-by: Patrick Wildt <patrick@blueri.se> Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> 
This allows our EFI API to create a device path node for NVMe
devices.  It adds the necessary device path struct, uses the
nvme namespace accessor to retrieve the id and eui64, and also
provides support for the device path text protocol.

Signed-off-by: Patrick Wildt <patrick@blueri.se>
Tested-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
efi_loader: volume name in EFI_FILE_PROTOCOL.GetInfo() 2019-09-09T13:21:09+00:00 Heinrich Schuchardt xypron.glpk@gmx.de 2019-09-08T08:32:54+00:00 632834ce6dc9905cb101c91903e8bea5224e1b72 We cannot determine the volume name in U-Boot. Instead of providing a dummy volume name in case of EFI_FILE_SYSTEM_INFO and EFI_UNSUPPORTED in case of EFI_FILE_SYSTEM_VOLUME_LABEL consistently return an empty string. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> 
We cannot determine the volume name in U-Boot. Instead of providing a dummy
volume name in case of EFI_FILE_SYSTEM_INFO and EFI_UNSUPPORTED in case of
EFI_FILE_SYSTEM_VOLUME_LABEL consistently return an empty string.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>