[PATCH 3/8] qemu: arm64: Add support for efi firmware management protocol routines

[Heinrich Schuchardt]

On 4/30/20 9:13 PM, Sughosh Ganu wrote:
>
> On Fri, 1 May 2020 at 00:09, Heinrich Schuchardt <xypron.glpk at gmx.de
> <mailto:xypron.glpk at gmx.de>> wrote:
>
>     On 4/30/20 7:36 PM, Sughosh Ganu wrote:
>     > Add support for the get_image_info and set_image routines, which are
>     > part of the efi firmware management protocol.
>     >
>     > The current implementation uses the set_image routine for updating the
>     > u-boot binary image for the qemu arm64 platform. This is supported
>     > using the capsule-on-disk feature of the uefi specification, wherein
>     > the firmware image to be updated is placed on the efi system partition
>     > as a efi capsule under EFI/UpdateCapsule/ directory. Support has been
>     > added for updating the u-boot image on platforms booting with arm
>     > trusted firmware(tf-a), where the u-boot image gets booted as the BL33
>     > payload(bl33.bin).
>     >
>     > The feature can be enabled by the following config options
>     >
>     > CONFIG_EFI_CAPSULE_ON_DISK=y
>     > CONFIG_EFI_FIRMWARE_MANAGEMENT_PROTOCOL=y
>     >
>     > Signed-off-by: Sughosh Ganu <sughosh.ganu at linaro.org
>     <mailto:sughosh.ganu at linaro.org>>
>
>     U-Boot's UEFI subsystem should work in the same way for x86, ARM, and
>     RISC-V. Please, come up with an architecture independent solution.
>
>
> Please check the explanation that I gave in the other mail. If you check
> the patch series, the actual capsule authentication logic has been kept
> architecture agnostic, in efi_capsule.c. The fmp protocol is very much
> intended for allowing platforms to define their firmware update
> routines. Edk2 also has platform specific implementation of the fmp
> protocol under the edk2-platforms directory.
>
> -sughosh
>  
>

My idea is that for most platforms it will be enough to have a common
FMP implementation that consumes a capsule

* with one or more binaries
* a media device path, a start address, and a truncation flag
  for each of the binaries

The protocol implementation then will write the binaries to the device
paths:

* to an SD-Card or eMMC exposing the Block IO protocol
  for most devices
* to a file in case of the Raspberry Pi or the Sandbox or QEMU
  (and truncate it if the truncation flag is set)

If for some devices like a SPI flash we do not have a media device path
yet, then the only platform specific bit would be the block device
driver exposing the media device path.

Same with a semi-hosted file: just add a driver exposing it as a media
path with an EFI_BLOCK_IO_PROTOCOL.

For security reasons it may be advisable to make the device read-only
when reaching ExitBootServices() or even better before the first
execution of StartImage(). For this purpose we could use the Reset()
service of the EFI_BLOCK_IO_PROTOCOL or provide a U-Boot specific
service in the EFI_BLOCK_IO_PROTOCOL.

Best regards

Heinrich