Fit images and EFI_LOAD_FILE2_PROTOCOL

[Ard Biesheuvel]

On Tue, 6 Oct 2020 at 17:09, François Ozog <francois.ozog at linaro.org> wrote:

>
>
> On Tue, 6 Oct 2020 at 16:46, Ard Biesheuvel <ardb at kernel.org> wrote:
>
>>
>>
>> On Tue, 6 Oct 2020 at 16:22, François Ozog <francois.ozog at linaro.org>
>> wrote:
>>
>>> Ard, there is a question for you in the below thread ;-)
>>>
>>> On Tue, 6 Oct 2020 at 15:02, Grant Likely <grant.likely at arm.com> wrote:
>>>
>>>>
>>>>
>>>> On 06/10/2020 13:52, Heinrich Schuchardt wrote:
>>>> > On 06.10.20 14:43, Grant Likely wrote:
>>>> >
>>>> >>
>>>> >> Current U-Boot by default uses the same DT image for both U-Boot
>>>> >> internal setup and to provide to the OS. This should be split so that
>>>> >> the U-Boot internal version has what U-Boot needs without needs to
>>>> track
>>>> >> mainline Linux DTB schema.
>>>> >>
>>>> >> I've been looking into a generic config for adding a separate OS-dtb
>>>> to
>>>> >> U-Boot that is not used internally and is only passed to the OS. That
>>>> >> would solve the problem you're seeing above.
>>>
>>> >
>>>> > What would be the advantage of building said second device-tree into
>>>> > U-Boot instead of loading it from a (possibly signed) file?
>>>>
>>>> I would see that as an implementation detail, but from the OS point of
>>>> view EBBR requires the firmware to provide a DTB to the OS without the
>>>> OS having any involvement in providing it. The easiest solution is to
>>>> embed the OS dtb into U-Boot, but it could be loaded and verified from
>>>> a
>>>> file as well.
>>>>
>>> To strongly state that the DT is a hardware description entity,
>>> disconnected from open source projects consuming it,
>>>  I would still build the DT for the Booted Payload in the context of
>>> devicetree.org and append it to either FIP or U-Boot.
>>> From a hierarchical perspective FIP would make more sense (I was told by
>>> the LinuxBoot guys that the ACPI tables are
>>> tied to PEI so that they can use them while replacing EDK2. I am not
>>> sure my understanding is correct: Ard ?)
>>>
>>
>> No that is a lie. In EDK2 based firmwares, there are DXE protocols used
>> for publishing and manipulating ACPI tables, and for exposing them via the
>> config table array when the boot finally occurs.
>>
>> Are the ACPI tables "static" blobs that are integrated into the firmware
> image with some late fixups in the DXE phase or are they entirely built
> programmatically during the DXE phase? In the case they are static base
> blobs in the firmware image, are they used (to access hardware, not
> manipulated) in all phases (SEC, PEI, DXE) ?
>

They could be generated from scratch or incorporated fully baked. In either
case, the firmware itself never consumes the ACPI tables, it only produces
them for consumption by the OS.


>
>
>> I should also point out (for anyone that hadn't noticed) that the
>> Linuxboot guys have a highly skewed and opinionated view of UEFI boot,
>> which seems mostly based on bad experiences with IBV provided, OEM mangled
>> builds for proprietary code bases of which it is unknown how much they are
>> based on EDK2 (or UEFI for that matter). The IBVs used to claim that they
>> carried their own complete implementations of the PI and UEFI and
>> specifications, but everybody knows that is a lie, especially for firmwares
>> built for ARM machines.
>>
>> as I consider that PEI and TF-A are at the same layer I am inclined to
>>> promote this.
>>>
>>
>> TF-A is secure firmware, PEI is non-secure firmware, so I suppose it
>> depends on how you defined your layers. Although in the x86 context, PEI
>> executes when the SMM execution context has not split off yet, so it s
>> closer to a secure world firmware than it is on ARM (same applies to DXE
>> before EndOfDxe, but the boundary line is not as clear in this case)
>>
> I was biased by the x86 model here...
>
>>
>>
>> Should the DTB cause problems, the one embedded in the FIT would be
>>> replacing the platform base one
>>>  (I assume this is your "loaded and verified from a file" comment).
>>>
>>>>
>>>> g.
>>>>
>>>
>>>
>>> --
>>> François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
>>> T: +33.67221.6485
>>> francois.ozog at linaro.org | Skype: ffozog
>>>
>>>
>
> --
> François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
> T: +33.67221.6485
> francois.ozog at linaro.org | Skype: ffozog
>
>