From mboxrd@z Thu Jan  1 00:00:00 1970
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
Date: Tue, 6 Oct 2020 14:36:23 +0200
Subject: Fit images and EFI_LOAD_FILE2_PROTOCOL
In-Reply-To: <CAHFG_=VJ5djd8fy7D611HyR8wifu15ZtSKBAFHVC9PnBL8_24Q@mail.gmail.com>
References: <951b8fca-da6b-c4bb-8e5a-fc96646f7f07@gmx.de>
 <1b8fc3ff-ac50-6f70-db61-30f67dd69151@arm.com>
 <9B772910-62A9-4770-AE55-77460D1F369F@gmx.de>
 <70e79c8d-ad3f-f08b-1527-1d3cfb87fde9@arm.com>
 <CAHFG_=VJ5djd8fy7D611HyR8wifu15ZtSKBAFHVC9PnBL8_24Q@mail.gmail.com>
Message-ID: <2cb94bde-7e44-3fe7-dcdc-509b64b6fe4b@gmx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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.

If Linux does not run with the device tree of the same version, how can
we hope for forward/backward compatibility?

Who takes care that other operating systems (e.g. BSD) are not broken by
DTB changes?

> - the resulting DTB is compiled and integrated by the platform vendor in
> its TF-A FIP at NT_FW_CONFIG section.
> - the platform vendor creates a FIT with the desired tuple
> - an EFI application is actually "booting" that FIT verifying both the
> initrd and the replacement DTB
> - at boot time, TF-A verifies DTB, pass it to U-Boot, U-Boot passes that
> DTB to the EFI application as a config table; The EFI application hooks
> the EFI BS (much like the SHIM does) so that EFI_LOAD_FILE2 of initrd
> goes to the FIT (uefi_merge_fs idea in the slide 5); vmlinuz is verified
> launched via UEFI mechanism, Linux EFI stub gets the initrd with
> EFI_LOAD_PROTOCOL2 which happens to be transparently redirected to the
> FIT (so the initrd is validated as in A.2).

The FIT image file format is not needed here. It is sufficient that the
vendor provides a signed binary that supplies the kernel, initrd, fdt
triplet. There is no need to specify how this binary works internally.

Best regards

Heinrich

>
> _____________??
> Identifying the right flow is the third point to decide on. I hope we
> can achieve this result on the October 14th call. If we agree on
> the?first two points,?the mail thread shall be such that we find
> consensus on how to implement the intention, the above description and
> slide 4/5 in the deck being just starting points. We can go in an entire
> direction.
>