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? _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
