Le mer. 5 juin 2019 à 10:07, Mills, William wmills@ti.com a écrit :
This seems over designed.
If the DT comes from the firmware the firmware needs to verify the DT signature in a maner that it is happy with.
If the OS provides the DT the OS loader verifies the DT in a maner it is happy with.
DONE.
Why is it more complex than this?
In a traditional embedded world where most of things are custom. There are
no problems to solve and as you say, this is a right pocket / left pocket problem.
Now value chain is evolving and need standard OTA, standard stacks where OS is a common block. So the traditional way need to go away from “haute couture” to “mass market. So the hardware description life cycle shall evolve to easily integrate into those standardized procedures. Yet it will be more difficult than ACPI because the diversity is much bigger and the diversity of trust authorities will be bigger. So reducing the number of moving parts is desirable. And the DT is clearly something that shall be less “custom” yet very flexible.
Bill
*From:* Francois Ozog [mailto:francois.ozog@linaro.org] *Sent:* Wednesday, June 5, 2019 9:55 AM *To:* Tom Rini *Cc:* Ard Biesheuvel; Grant Likely; Heinrich Schuchardt; Ilias Apalodimas; boot-architecture@lists.linaro.org; nd; Loic Pallardy; Mills, William; Peter Robinson *Subject:* DT and EBBR, was: Securing the boot flow in U-Boot
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
- "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)
- 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.
- OS payload signing and verification: was the original topic of the
discussion and shall continue in the other thread.
- 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
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog