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

[Heinrich Schuchardt]

On 05.05.20 19:23, Grant Likely wrote:
>
>
> On 05/05/2020 18:04, Heinrich Schuchardt wrote:
>> On 05.05.20 13:15, Grant Likely wrote:
>>>
>>>
>>> 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.
>>
>> A block device, a partition, and a file all can be described by an UEFI
>> media device path.
>
> Sure, from a UEFI media path, but does the underlying U-Boot
> implementation have that abstraction?


With a file media path we can find the partition device path on which
the Simple file protocol is already installed by U-Boot.

>
>>> 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.
>>
>> I would prefer one single FMP driver for all SMC use cases. Everything
>> device specific should be handled in the secure world.
>
> Not all platforms will be able to put firmware update into the secure
> world. For instance, Not many Arm v7 platforms have trustzone accessible
> to open source developers. On non-secure platforms (e.g., anything that
> loads firmware from a regular filesystem on SD or eMMC) it doesn't make
> much sense to loop out to secure firmware when U-Boot owns the
> filesystem and the secure world would then need to coordinate with
> U-Boot to commit the writes.
>
> All of the code can certainly be in the same location, but I do think
> there are three distinct generic backends for firmware updates:
> - normal-world file-backed (using filesystem)
> - normal-world block-backed (offsets from start of device)

These two could be in one instance of the FMP protocol.

> - secure device backed (needs to go into secure world for unpacking and
> processing regardless)
>
> There doesn't need to be platform-specific code in any of those back
> ends, but they do have different behaviour.
>
>>
>> Is there already a protocol defined for the communication of capsule
>> updates between the firmware and the secure monitor, e.g. in EDK2?
>
> Nothing defined yet (see below)
>
>> Would we simply use the UpdateCapsule() call parameters and pass them
>> via an SMC call?
>
> If secure world is handling the update? Yes, I think a thin
> UpdateCapsule() SMC makes sense, with the bonus that UpdateCapsule() at
> runtime becomes feasible on U-Boot. There are a couple of people inside
> Arm looking at possible interfaces. In this situation there is very
> little done in normal-world at all.
>
> [...]
>
>>
>> According to my call with Sughosh the whole semihosting thing is about
>> providing a testing possibility not about any real use case.
>
> Yes, it's for testing, but it is particularly valuable testing because
> it allows the host filesystem to be exposed into QEMU. Exposing
> semihosting as a generic fstype_info in U-Boot is generically useful
> apart from this entire discussion!  :-)
>
> If we rework the semihosting code to be just another FS driver, then I
> think it is just an implementation detail on the file-backed firmware
> update path.

In this case it could be completely separate from this patch series.

Where do you see the benefit of semi-hosting compared to mounting an image?

Best regards

Heinrich

>
>> On QEMU you can easily mount an image as block device using parameters
>> of the qemu-system-* command. On the mounted image/block-device you can
>> test both file and block device based firmware updates. On the sandbox
>> you could use the 'host bind' command for mounting an image.
>
> Similar to the above, this would be an implementation detail on the
> block-device backed firmware update path. We need both.
>
> g.
> 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.