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

[Grant Likely]

On 01/05/2020 10:33, Heinrich Schuchardt wrote:
> 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)

Does U-Boot have a common device path protocol that can be backed by
either a block device or a file on a filesystem? I didn't think it did.

In the mean time, there are at least three backends that the FMP is
going to have to deal with; the two you list above (block device & file)
and SMC backed when updating firmware is managed by the secure world.
This first implementation only handles the file-backed use case. Can we
start with that limitation and refactor when the block-device and SMC
use cases are added in? I would hate to see this functionality held up
on having to refactor other functionality in U-Boot.

> 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.

Sughosh and I chatted about this and took a look a the semihosting
driver. Right now it is a standalone component implementing only the
smhload command. It looks like it easily maps onto fstype_info
operations which would be a better fit than the block IO protocol. Am I
correct in assuming that would also make semihosting available to the
EFI_FILE_PROTOCOL? The FMP backend code could be common for all
filesystem targets, with the only platform specific bit being the path
to the firmware files.

How does that sound?

g.

> 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
>
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.