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