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