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/1JK00su6e7vt8lRfwSt2C9EuuzwcBHLyoLRRr... 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.