On Tue, 4 Jun 2019 at 10:17, Heinrich Schuchardt <[email protected]> wrote:
> > > 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. > > In a perfect world, U-Boot shall lead and we should work towards that if not in place. There is no sch a thing as a Linux validated ACPI table, so why for DT? Logically, it makes no sense to me, the firmware is hardware dependent/aware and shall be the authority. OS just a user. Worse, if an OS does not comply it shall be considered as a security breach. > Best regards > > Heinrich > -- 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
