Fit images and EFI_LOAD_FILE2_PROTOCOL

[François Ozog]

On Tue, 6 Oct 2020 at 14:36, Heinrich Schuchardt <xypron.glpk at gmx.de> 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.
>
> 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?
>
Trying to address all the above with this:
qemu-bsa is essentially about virtio devices which are discovered through
virtio and not DT.
Linaro is further involved in virtio devices for random number generator,
SCMI and watchdog.
The compatibility issues are limited to platform devices and services such
as: GIC,  PSCI and may be others (I would prefer to have virtio-console
rather than PL01 for instance)
So I think the scope of the proof of concept is small enough to be
manageable.
The proof of concept would be to allow Linux and freeBSD on arm64.
Linaro and its members would be responsible to make that happen.
Some platforms will be EBBR compliant, some not. Should a platform vendor
want to have an EBBR flow, it should have the power to choose to make it
work and not depend on other vendors to embrace the model.
This is leading by example: by itself the PoC will not solve the whole
problem for all platforms. Merely show the way. And with a lot of good
will, situations may change over time (5 years?).


>
> > - 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.
>
> Indeed. The idea is to have one reference model based on something
available.

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.
> >
>


-- 
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog