Le mar. 4 juin 2019 à 17:31, Tom Rini <[email protected]> a écrit :
> On Tue, Jun 04, 2019 at 10:25:23AM -0400, Francois Ozog wrote: > > 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? > > There _is_ such a thing as a validated ACPI table and functionally ACPI > tables on x86 are validated with Windows. This is no different. > I think it may be good to validate but not provide. There is no Linux provided ACPI table right ? So I get the point to validate a DT. > > -- > Tom > -- 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
