On Tue, 4 Jun 2019 at 15:55, Francois Ozog <[email protected]> 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. > > > But my point remains the same. If we are accommodating a model where the DT is shipped with the OS, the OS can deal with authenticating the DTB files. If the firmware provides the DT, it is a firmware implementation detail how and where it keeps the DTB files internally, as long as it uses the official way (i.e., via a UEFI config table) to expose the DT to the OS. Rolling all of this into secure boot support (which deals with authenticating OS components/loaders to the firmware) is something we should avoid. _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
