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

Sat May 9 12:04:22 CEST 2020

On 5/6/20 5:04 PM, Grant Likely wrote:
>
>
> On 05/05/2020 18:57, Heinrich Schuchardt wrote:
>> 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?
>
> Both are important. We need test benches for both file and block device
> update scenarios.
>
> g.
>
>>
>> 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.
>>
> 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.

[08.05  23:22] <apalos> who will provide the file path protocol and
potential offsets?
[09.05  12:02] <xypron> The media device path and the offsets have to be
provided by the one who builds the capsule and the must be integral part
of the capsule.

Best regards

Heinrich