u-boot.git/lib, branch v2022.07-rc4

efi: test/py: authenticate fit capsules

2022-06-04T06:43:55+00:00

Add support for the authentication of UEFI capsules containing FIT images.

The authentication code is moved out of the function handling raw images
into a new function efi_firmware_capsule_authenticate(). The special case
for the FMP header coming from edk2 tools is preserved. There is no
functional change for capsules containing raw images.

The python test for signed capsules with raw images is renamed with no
functional change and a new test is added for signed capsules containing
FIT images.

This can be tested with sandbox64_defconfig or sandbox_flattree_defconfig,
plus CONFIG_EFI_CAPSULE_AUTHENTICATE=y.

Signed-off-by: Vincent Stehlé 
Cc: Heinrich Schuchardt

EFI: Populate descriptor_count value only when image_info_size is not zero

2022-06-04T06:43:55+00:00

The GetImageInfo function of the Firmware Mangement Protocol(FMP) gets
called initially to query the size of the image descriptor array that
would have to be allocated. During this call, the rest of the function
arguments, specifically pointers might be passed as NULL. Do not
populate the descriptor_count value before it is known that the call
to GetImageInfo has been made with the allocated buffer for the image
descriptors.

Signed-off-by: Sughosh Ganu 
Reviewed-by: Heinrich Schuchardt

efi: fix documentation warnings

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

This fixes the following warnings:

  ./lib/efi_loader/efi_firmware.c:283: warning: Function parameter or member 'package_version' not described in 'efi_firmware_fit_get_image_info'
  ./lib/efi_loader/efi_firmware.c:283: warning: Function parameter or member 'package_version_name' not described in 'efi_firmware_fit_get_image_info'
  ./lib/efi_loader/efi_firmware.c:369: warning: bad line: firmware image
  ./lib/efi_loader/efi_firmware.c:395: warning: Function parameter or member 'package_version' not described in 'efi_firmware_raw_get_image_info'
  ./lib/efi_loader/efi_firmware.c:395: warning: Function parameter or member 'package_version_name' not described in 'efi_firmware_raw_get_image_info'

Signed-off-by: Vincent Stehlé 
Cc: Heinrich Schuchardt 
Reviewed-by: Heinrich Schuchardt

efi_loader: bootmgr: fix a problem in loading an image from a short-path

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

Booting from a short-form device path which starts with the first element
being a File Path Media Device Path failed because it doesn't contain
any valid device with simple file system protocol and efi_dp_find_obj()
in efi_load_image_from_path() will return NULL.
For instance,
/VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/Scsi(0,0)/\helloworld.efi
-> shortened version: /\helloworld.efi

With this patch applied, all the media devices with simple file system
protocol are enumerated and the boot manager attempts to boot temporarily
generated device paths one-by-one.

This new implementation is still a bit incompatible with the UEFI
specification in terms of:
* not creating real boot options
* not try
  "If a device does not support the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, but
  supports the EFI_BLOCK_IO_PROTOCOL protocol, then the EFI Boot Service
  ConnectController must be called for this device with DriverImageHandle
  and RemainingDevicePath set to NULL and the Recursive flag is set to TRUE."
(See section 3.1.2 "Load Option Processing".)

But it still gives us a closer and better solution than the current.

Fixes: commit 9cdf470274ff ("efi_loader: support booting via short-form device-path")
Signed-off-by: AKASHI Takahiro 
Reviewed-by: Heinrich Schuchardt

efi_loader: disk: add efi_disk_is_removable()

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

This helper function will be used to determine if the device is
removable media, initially for handling a short-path loading.

Signed-off-by: AKASHI Takahiro 
Reviewed-by: Heinrich Schuchardt

efi_loader: add sha384/512 on certificate revocation

2022-05-07T21:17:26+00:00

Currently we don't support sha384/512 for the X.509 certificate
in dbx.  Moreover if we come across such a hash we skip the check
and approve the image,  although the image might needs to be rejected.

Rework the code a bit and fix it by adding an array of structs with the
supported GUIDs, len and literal used in the U-Boot crypto APIs instead
of hardcoding the GUID types.

It's worth noting here that efi_hash_regions() can now be reused from
efi_signature_lookup_digest() and add sha348/512 support there as well

Signed-off-by: Ilias Apalodimas

efi_loader: Select EVENT as well

2022-05-07T21:17:26+00:00

Fixes

WARNING: unmet direct dependencies detected for EVENT_DYNAMIC
  Depends on [n]: EVENT [=n]
  Selected by [y]:
  - EFI_LOADER [=y] && OF_LIBFDT [=y] && ...

and the succeeding build breakage.

Signed-off-by: Jan Kiszka 
Reviewed-by: Heinrich Schuchardt

lib/date: Make rtc_mktime and mktime64 Y2038-ready

2022-05-05T19:06:02+00:00

We currently overflow due to wrong types used internally in rtc_mktime,
on all platforms, and we return a too small type on 32-bit.

One consumer that directly benefits from this is mktime64. Many others
may still store the result in a wrong type.

While at it, drop the redundant cast of mon in rtc_mktime (obsoleted by
714209832db1).

Signed-off-by: Jan Kiszka

efi_loader: bootmgr: add booting from removable media

2022-05-03T19:39:22+00:00

Under the current implementation, booting from removable media using
a architecture-specific default image name, say BOOTAA64.EFI, is
supported only in distro_bootcmd script. See the commit 74522c898b35
("efi_loader: Add distro boot script for removable media").

This is, however, half-baked implementation because
1) UEFI specification requires this feature to be implemented as part
   of Boot Manager's responsibility:

  3 - Boot Manager
  3.5.1 Boot via the Simple File Protocol
  When booting via the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, the FilePath will
  start with a device path that points to the device that implements the
  EFI_SIMPLE_FILE_SYSTEM_PROTOCOL or the EFI_BLOCK_IO_PROTOCOL. The next
  part of the FilePath may point to the file name, including
  subdirectories, which contain the bootable image. If the file name is
  a null device path, the file name must be generated from the rules
  defined below.
  ...
  3.5.1.1 Removable Media Boot Behavior
  To generate a file name when none is present in the FilePath, the
  firmware must append a default file name in the form
  \EFI\BOOT\BOOT{machine type short-name}.EFI ...

2) So (1) entails the hehavior that the user's preference of boot media
   order should be determined by Boot#### and BootOrder variables.

With this patch, the semantics mentioned above is fully implemented.
For example, if you want to boot the system from USB and SCSI in this
order,
* define Boot0001 which contains only a device path to the USB device
  (without any file path/name)
* define Boot0002 which contains only a device path to the SCSI device,
and
* set BootOrder to Boot0001:Boot0002

To avoid build error for sandbox, default file name "BOOTSANDBOX.efi"
is defined even if it is out of scope of UEFI specification.

Signed-off-by: AKASHI Takahiro 
Signed-off-by: Masahisa Kojima 
On sandbox use binary name corresponding to host architecture.
Reviewed-by: Heinrich Schuchardt

efi_loader: export efi_locate_device_handle()

2022-05-03T19:39:22+00:00

This function will be used in the next commit where some behavior
of EFI boot manager will be expanded.

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