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

5 Jun 2019


      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>).
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.
Le mer. 5 juin 2019 à 08:35, Tom Rini trini@konsulko.com a écrit :
...
On Wed, Jun 05, 2019 at 08:29:37AM +0200, Ard Biesheuvel wrote:
...
On Wed, 5 Jun 2019 at 00:34, Tom Rini trini@konsulko.com wrote:
...
On Tue, Jun 04, 2019 at 06:14:16PM -0400, Francois Ozog wrote:
...
Le mar. 4 juin 2019 à 17:31, Tom Rini trini@konsulko.com a écrit :
...
...
...
I think it may be good to validate but not provide. There is no Linux
provided ACPI table right ? So I get the point to validate a DT.
There's "Linux provided" ACPI tables when someone has to decompile,
fixup and re-compile their DSDT files.
Or perhaps a better way to think of it is that yes, there's "Linux
provided ACPI tables" when vendors are developing their hardware and
correcting their ACPI tables.  Same thing with DT, by and large (as
overlays and secure boot are a can of worms to worry about later).
Secure boot enabled Linux does not permit this model. Side loading of
DSDTs/SSDTs is disabled by the hardening patchset that all the distros
carry for secure boot enabled kernels.
That sounds a little broken then.  It should be doable so long as the
files are signed appropriately.  It's also rarer because the ACPI tables
are functionally validated before they're put into production.  That's
largely the case here, except when we're talking about updating them for
new support or just like the case above, fixing a problem with them.
--
Tom