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. -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
