Fit images and EFI_LOAD_FILE2_PROTOCOL

[Grant Likely]

On 06/10/2020 13:36, Heinrich Schuchardt wrote:
> On 06.10.20 14:04, François Ozog wrote:
>> As always, Ard made a good point, and I feel compelled to top post and
>> restate stuff.
>>
>> Here is the supporting deck:
>> https://docs.google.com/presentation/d/1JK00su6e7vt8lRfwSt2C9EuuzwcBHLyoLRRrdcYfVWY/edit?usp=sharing
>>   
>> We have two boot flows under consideration (not saying others are bad,
>> just to say they are on focus):
>> A.1 typical distro (slide 2): <EFI firmware/ACPI> --> <shim> --> <grub>
>> --> Linux; Linux is here defined as the tuple {vmlinuz}, vmlinuz is
>> verified through EFI mechanism by either efi firmware or shim,  ACPI
>> tables are verified by firmware, initrd is not verified
>> A.2 typical embedded (slide 3): <firmware/DT> -> Linux ; Linux is here
>> defined as the tuple {vmlinuz, initrd, dtb} that is folded into a FIT
>> and are verified via signature, it avoid errors/attacks about mixing
>> vmlinuz/initrd/dtb.
>>
>> We want EBBR "equivalent" flows (Equivalent meaning with the same level
>> of security and accepting the weaknesses).
>> B.1 typical distro (slide 4): <EFI firmware/DT> --> <shim> --> <grub>
>> --> Linux
>> B.2 typical embedded (slide 5): <EFI firmware/DT> -> Linux
>>
>> For B.1 to be equivalent to A.1, we need the DT to be authenticated
>> (ACPI is embedded in the firmware in A.1).
>> For B2. to be equivalent to A.2, we  need the DT and initrd to be
>> authenticated
>>
>> _____________
>> We can first validate this point: let's check whether we want to do this
>> (regardless of the implementation details, focusing on the intention).
>>
>>
>>
>> On the implementation side, last call we discussed Trusting DT and we
>> ended up talking about trusting initrd too (probably because B.2 in the
>> back of our minds, without being explicit about this).
>>
>> After giving some additional thoughts, it sounds like a good approach is
>> to "lead by example": let's implement what we think are the "archetype"
>> flows for Qemu and maintain it over time. We would make all changes we
>> think are good in all relevant projects (tfa, op-tee, u-boot,
>> devicetree, linux kernel, qemu...). Being an "archetype" flow does not
>> prevent systems to be EBBR compliant, we just have reference flows.
>>
>> _____________
>> We can validate this second point: are we in agreement that leading by
>> an end-to-end example on a platform, rather by technology layers
>> (trusting DT PoC was in that spirit) ?
>>
>>
>>
>> What are the implementation details of B.1 and B.2?
>>
>> B.1
>> To trust DT the proposal is to make its use closer to ACPI: this is a
>> platform attribute that is verified by firmware and handed over to OS.
>> To achieve that:
>> - we create a platform repo in devicetree.org <http://devicetree.org>,
>> add the Qemu-bsa DT (coming from current Linux kernel ), and maintain it
>> over time. We shall ensure forward/backward compatibility of relevant
>> Linux drivers.
>> - the resulting DTB is compiled and integrated by the platform vendor in
>> its TF-A FIP at NT_FW_CONFIG section.
> 
> When building OpenSBI you can specify a device-tree using environment
> variable FW_PAYLOAD_FDT_PATH.
> 
>> - at boot time, TF-A verifies DTB, pass it to U-Boot, U-Boot passes that
>> DTB to the shim as a config table and boot flow continues; the platform
>> DTB can be overridden by grub (without any verification, that can be
>> seen as a weaker than ACPI case); the Linux EFI-STUB uses EFI_LOAD_FILE2
>> protocol to get the initrd (unverified). Linux command line dtb= is disabled
>>
>> B.2
>> To trust DT the proposal is to make its use closer to ACPI: this is a
>> platform attribute that is verified by firmware and handed over to OS.
>> To trust the initrd the proposal is to leverage the same concept as A.2:
>> create a tuple with {vmlinuz, initrd, dtb}
>> To achieve that:
>> - we create a platform repo in devicetree.org <http://devicetree.org>,
>> add the Qemu-bsa DT (coming from current Linux kernel ), and maintain it
>> over time. We shall ensure forward/backward compatibility of relevant
>> Linux drivers.
> 
> QEMU provides its own device-tree to the firmware. Why would we need a
> Linux device-tree for QEMU?
> 
> The Linux Foundation is unable to ensure that their device-trees are
> usable. With a Linux DTB after v5.3 I cannot start my MacchiatoBin with
> v5.4-v5.7.

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.

That doesn't solve the problem of DTB schema stability, but it at least 
decouples the problem so we're not stuck.

g.