Fit images and EFI_LOAD_FILE2_PROTOCOL

[Grant Likely]

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.

g.