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.
