On Wed, 5 Jun 2019 at 14:59, Tom Rini trini@konsulko.com wrote:

On Wed, Jun 05, 2019 at 09:17:04AM +0100, Graeme Gregory wrote:

...

On Wed, 5 Jun 2019 at 07:36, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:

...

On Wed, 5 Jun 2019 at 00:41, Tom Rini trini@konsulko.com wrote:

...

...

...

It depends on what you mean by "OS provided". The DTS files come from the Linux Kernel sources, full stop.

That is the mistake we should try to fix.

We have DT bindings, which define the contract between the OS on one side, and the platform on the other side. This means it is the platform's job to present a DT description that adheres to those [stable] bindings.

Today's development model of developing DT bindings in lockstep with the drivers, and then bundling DT files with the OS is completely unsustainable, since it doesn't scale, and it demonstrably results in DT bindings that get modified without any regard for devices that are already in the field (MacchiatoBin is a good example).

So it doesn't really matter where the kernel *sources* come from, as long as the platform provides its own DT, which does not change just because the kernel changes.

It is already defined how the platform provides this DT on a UEFI system, i.e., via a configuration table with a known GUID. How the firmware popiulates this memory is an implementation detail: if it wants to load it from a signed file in the file system, that is fine, as long as it is not the OS providing this file to the firmware.

I agree, people seem to be conflating where DT is stored in source control over where it should be supplied to OS.

Just because the DT is in linux kernel git does not mean you can't build it into the u-boot for your board.

In fact I bet u-boot maintainer would love patches for updates ;-)

Right. But there's also confusion about where the DTB is to be found. Whereas ACPI is "burned in" the DTB (generally) is not and will not be. It will be loaded from storage, so in the context of this overall thread, figuring out how to verify the signature on the DTB is a main use case.

There is no confusion at all. On a UEFI/EBBR system, the DT shall be provided to the OS via a config table using the established GUID. How the firmware achieves that is left unspecified. The fact that it may be loaded from storage does not make it part of the packaged OS, it is still a component of the platform.

But based on this discussion, I will argue going forward that - the firmware must not rely on the OS to put DT images under known names into known locations in the file system, - the firmware provides this DT regardless of which keys are loaded into the uefi secure boot keyring, IOW, if i choose to put only the RedHat certificate in db because that is all i care about, I don't want to end up with a bricked system because the DT was loaded via the secure boot stack and was signed with the Microsoft keyring.

Btw, the fact that Authenticode/PE-COFF does not permit multiple signatures does not make things any easier.