Re: DT and EBBR, was: Securing the boot flow in U-Boot

On 6/5/19 3:55 PM, Francois Ozog wrote:

So trying to summarize the DT side track discussion in a different thread:

( Shall we organize a virtual design sprint before the end of the month? I'd like to create a section from the discussion in Boot Flows documen )

I - Current situation is:

• DT provided by Linux kernel because it was “easier” and there was no

upstream home

• ACPI is provided by firmware (to make things simple), non secure OS can

patch them in case of issues, SecureBoot prevents those patches

OS provided DT is a cool developer facility in the context of floating DT bindings and lack of proper upstream project. But conceptually speaking, DT is not an OS thing and is not a firmware thing: it is a board thing that may be massaged by firmware and consumed by OS.

With EBBR we seek a clean and salable solution that make the DT as simple as ACPI.

II - Desired DT for EBBR policy

1. "upstream" DT

1.1) who provides DT Board vendor make a <reference DT> that describes every hardware piece, firmware provides a DT to OS, OS may be able to validate the DT but not override it in secureboot production. For security and boot latency consideration, firmware may actually need two DTs: a stripped version from <reference DT> to operate on the minimal set of devices it want to bring up the OS (say the <firmware DT>), a pruned/adapted version from <reference DT> , ie without devices firmware wants to control and conforms to EBBR spec (say the <OS DT>).

Can we get the Linux Foundation involved to integrate their view?

Regards

Heinrich

1.2) upstream <reference DT> The board reference DT> shall be valid regardless of the firmware (may be trusted firmware, uboot, edkII, linuxBoot...) not mentioning OS! There are many candidates but I start to think Linaro could host a DT and EBBR companion community project: "EBBR DTs" that will contain all the <reference DT> from every EBBR compliant board vendor. (Other boards can continue the mess, it is irrelevant EBBR, and us. SecureBoot, MeasuredBoot implementations will assume EBBR compliance)

2. who sign what with what key

If we think of the following use case: Silicon Vendor provides a chip, a board vendor provides a board, ABB builds a controller, Caterpillar creates a mining truck with the controller, Rio Tinto operates the trck.

One possible (just designed to show case the need of various keysets) trust chain is:

- Board key db is loaded with a board vendor, ABB and caterpillar certs.
- Trusted firmware:  ABB doesn't want to deal with this, so the Board
vendor provides and signs trusted firmware, with key_tf.
- untrusted firmware: ABB selects the <firmware DT> and <OS DT> signs
both DTs and firmware with key_firmware. Trusted Firmware will validate the
signatures as key DB is loaded with ABB cert.
- grub and the OS: Caterpillar signs them with key_os (What is signed
and how it is verified is still a big discussion topic and the origin of
the sidetrack on DT)
- applications: Rio Tinto insurance company may be given the authority
to sign hosted OPTEE applications with a different key.

3. OS payload signing and verification: was the original topic of the

discussion and shall continue in the other thread.

4. operational considerations

In non SecureBoot environment, DT can be patched by OS (same as ACPI). OS may decide to verify validaty of provided DT (mechanism yet to be defined) "dtb=" kernel command line parameter is still possible in non secure boot but forbiden in secureBoot.