On Tue, 6 Oct 2020 at 15:12, Heinrich Schuchardt <[email protected]> wrote:
> On 06.10.20 14:46, Grant Likely wrote: > > > > > > On 06/10/2020 13:41, Ilias Apalodimas wrote: > >> Hi Grant, > >> > >> [...] > >>>>> > >>>>> Hi Heinrich, > >>>>> > >>>>> I've got concerns about this approach. Even though it uses the UEFI > >>>>> infrastructure, images deployed in this way are U-Boot specific and > >>>>> won't ever be applicable on EDK2 or other UEFI implementations. > >>>>> > >>>>> However there is another way to approach it which I think Francois > >>>>> touched on. If instead a UEFI stub was added to the FIT image, in the > >>>>> same way that the kernel has a UEFI stub, then the logic of decoding > >>>>> the > >>>>> FIT and choosing the correct DTB & initrd can be part of the image > and > >>>>> it becomes applicable to any UEFI implementation. It would also > >>>>> address > >>>>> > >>>>> Ard's concern of loading the FIT into memory, and then copying due to > >>>>> the EFI_FILE_LOAD2 path. The FIT stub would already know the image is > >>>>> in > >>>>> RAM, that is is reserved correctly, and just pass the correct > >>>>> addresses > >>>>> > >>>>> to the kernel as part of the normal boot flow. > >>>>> > >>>>> Signing would also be taken care of because the whole FIT can be > >>>>> signed, > >>>>> and that signature would be checked when it gets loaded. > >>>>> > >>>>> Thoughts? > >>>>> > >>>> > >>>> The gain of a fit image in U-Boot used for calling the Linux kernel > >>>> via the EFI stub vs calling the legacy entry point comes down to > >>>> providing the EFI_RNG_PROTOCOL to be used for KASLR. > >>> > >>> I agree with that, but that is not my concern. > >>> > >>> My concern is that the FIT image format will only be supported by > >>> U-Boot. > >>> Other UEFI implementations do not implement it. > >>> > >>> On the other hand, adding a UEFI Stub to the FIT image format makes it > a > >>> generic solution that can be used by any UEFI implementation. This > >>> would be > >>> separate from the linux kernel's UEFI stub, and should only deal with > >>> choosing the appropriate kernel/initrd/dtb from the FIT and then > calling > >>> into the kernel's stub to actually boot the kernel. > >> > >> If we are considering a cross-firmware solution for this why base it > >> on FIT? > >> Wouldn't a single EFI application (that's aware of the signatures and > how > >> to verify them) do the job? Just to inherit the work on signatures > >> already done > >> in FIT? > > > > Hahaha! I wasn't going to bring that up because I didn't want to cause > > extra trouble. :-) But yes, you're right. If we have a UEFI stub on the > > container, then it doesn't matter what the container format is. cpio, > > tar.gz, zip, FAT image, etc. Any of those would work. > > > >>>> For initrd a stub UEFI binary will work. But if you want to provide > >>>> a kernel specific dtb with the same stub binary it will require a > >>>> new service for device-tree fixups. > >>> > >>> Devicetree fixups indeed needs to be solved. I would propose > >>> registering a > >>> new protocol for fixups. If the protocol is present, then stub can > >>> call it. > >>> If not, then the DTB from the fit should be used unmodified. > >>> > >>> g. > >> > >> So if you do this in a single EFI app, you wont need an extra protocol > >> for it > >> right? > > > > True, you could embed the DT fixups into the EFI stub itself, but that > > would end up being completely separate logic from the fixup code already > > in U-Boot. > > Many fixups are hardware related. We should not write that logic twice. > > You could think of copying fixups from the firmware device-tree to the > stub device-tree but this too would be a very device specific solution. > > Having the firmware (e.g. U-Boot) do the fixup would provide a solution > that is much more generic. > Agreed. U-Boot actually should orchestrate fixups (the protocol you just proposed) and do its own fixups ([chosen][, serial numbers][, part numbers][, MAC addresses]...). > > Best regards > > Heinrich > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog
