Fit images and EFI_LOAD_FILE2_PROTOCOL

[Heinrich Schuchardt]

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.

Best regards

Heinrich