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

Heinrich Schuchardt xypron.glpk at gmx.de
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


More information about the U-Boot mailing list