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? Bill From: Francois Ozog [mailto:[email protected]] Sent: Wednesday, June 5, 2019 9:55 AM To: Tom Rini Cc: Ard Biesheuvel; Grant Likely; Heinrich Schuchardt; Ilias Apalodimas; [email protected]; 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 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 <[email protected]<mailto:[email protected]>> 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 > <[email protected]<mailto:[email protected]>> wrote: > > > > On Tue, Jun 04, 2019 at 06:14:16PM -0400, Francois Ozog wrote: > > > Le mar. 4 juin 2019 à 17:31, Tom Rini > > > <[email protected]<mailto:[email protected]>> 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 _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
