On 6/4/19 3:55 PM, Francois Ozog wrote: > On Tue, 4 Jun 2019 at 09:49, Ard Biesheuvel <[email protected]> > wrote: > >> >> >> On Tue, 4 Jun 2019 at 15:44, Francois Ozog <[email protected]> >> wrote: >> >>> Hi Ard, >>> >>> On Fri, 31 May 2019 at 13:35, Ard Biesheuvel <[email protected]> >>> wrote: >>> >>>> On Fri, 31 May 2019 at 19:25, Ilias Apalodimas >>>> <[email protected]> wrote: >>>>> >>>>> Hi Grant, >>>>>> I see two ways to handle this that fits with the Secure Boot >>>>>> authentication path: >>>>>> >>>>>> Option 1: Leave it to the OS loader >>>>>> We could simply say that if the OS wants to replace the DTB, then it >>>>>> should take care of authentication itself within the OS loader >>>> (possibly >>>>>> the in-kernel UEFI stub) and install a replacement DTB in the >>>>>> configuration table before calling exit boot services. In this >>>> scenario, >>>>>> U-Boot doesn't authenticate the DTB at all. >>>>>> >>>>>> In fact, Option 1 is pretty close to what is required for the initrd. >>>>>> >>>>>> I wonder if it is possible to wrap the DTB with a PE/COFF so that >>>> the os >>>>>> loader can use load_image to authenticate and retrieve the data >>>> without >>>>>> actually executing the image. That would allow for the DTB & initrd >>>> to >>>>>> be authenticated in the same way as the kernel. >>>>> I asked around on this prior to the email, but i think it boils down to >>>>> "UEFI is intended to authenticate bootable images for the platform", >>>> so i doubt >>>>> this will be allowed. >>>>> >>>> >>>> The point I raised when we discussed this is that UEFI is an interface >>>> between the firmware and the OS, and it is up to the firmware to >>>> *provide* the DT not the other way around. >>>> >>>> Whether the firmware reuses some of the existing machinery if it >>>> chooses to load the DT it provides from an arbitrary file on the file >>>> system is an implementation detail, and shouldn't be part of how we >>>> design the interface. The more we standardize this and the more we >>>> make it similar to how the OS loader is authenticated, the more likely >>>> it becomes that it will be relied upon for DTs that are bundled with >>>> the OS, which is a practice we are trying very hard to move away from. >>>> >>> >>> I have the impression that OS provided DT is a bad solution to a real >>> problem: >>> There should be a Firmware hardware environment (what to initialize, >>> use...) and a OS hardware environment. >>> Both should be signed, and controlled by the firmware. >>> So I would try to find a way to supply firmware with two DTs, or more >>> likely one DT and one OS overlay (if overlays can remove some hardware). >>> >>> >> >> If the OS provides a DT to itself, what is the point of pretending that it >> has been authenticated to the firmware? >> > Agreed, that is stupid! I mispresented my idea: I talk about two DTs > controlled by hardware/Firmware provider. OS shall be a consumer only. > >
In a perfect world firmware would provide the authoritative source of the device tree. The current situation has device trees developed in the context of Linux and U-Boot picking them up. U-Boot is lagging far behind Linux. Whenever I wanted to change a device tree in U-Boot I was told to first get that change into Linux. I see no commitment to change this process. Device-trees are provided by U-Boot to Linux as UEFI configuration tables. If a device-tree is malicious it may lead to the destruction of hardware. So whatever U-Boot provides as a device-tree to Linux should be validated. Best regards Heinrich _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
