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.g...@gmx.de >>>>>>> <mailto:xypron.g...@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.g...@linaro.org >>>>>>> <mailto:sughosh.g...@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