Le mar. 4 juin 2019 à 17:27, Tom Rini <[email protected]> a écrit :
> On Tue, Jun 04, 2019 at 10:21:54AM -0400, Francois Ozog wrote: > > On Tue, 4 Jun 2019 at 10:00, Ard Biesheuvel <[email protected]> > > wrote: > > > > > > > > > > > On Tue, 4 Jun 2019 at 15:55, Francois Ozog <[email protected]> > > > 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. > > >> > > >> > > >> > > > But my point remains the same. If we are accommodating a model where > the > > > DT is shipped with the OS, the OS can deal with authenticating the DTB > > > files. If the firmware provides the DT, it is a firmware implementation > > > detail how and where it keeps the DTB files internally, as long as it > uses > > > the official way (i.e., via a UEFI config table) to expose the DT to > the OS. > > > > > > Rolling all of this into secure boot support (which deals with > > > authenticating OS components/loaders to the firmware) is something we > > > should avoid. > > > > > Agreed. There is no such a thing as an OS provided ACPI table.... yet we > > allow that for DT... strange isn't it? > > I think we're getting a bit side tracked. And, depending on what you > want to call people having to fixup and recompile DSDT to fix issues... > :) > > The Linux Kernel happens to be the (generally) authoritative source of > DT files, rather than the hardware manufacturer. > To me it looks like walking on the head. I don’t see any OS providing an ACPI table. I think I understand why it happened. But to me it looks like a wrong solution to a real use case: firmware hardware execution environnement is different (probably smaller) than os execution environment. I think this is more about EBBR and it’s compliance. What shall be the right policy ? And then we refine EBBR. > > > So as a reference platform we can say that an OS provided DT is NOT part > of > > the picture. Yet if a vendor still wants to do it, it will be able to. We > > just don't care. > > > > Now, in the context of standard OTA across SoCs, what shall be > standardized > > to support the two DTs (for firmware execution and for OS execution). Are > > we considering UBoot firmware as a "blob" that embeds those two DTs? > Might > > be good enough. > > The common case is NOT going to be that the DT is provided embedded > within the hardware, please keep that in mind. > EBBR says: “Similarly, devices retained by firmware (i.e., not discoverable by the OS) shall not be accessed by the OS.” so an OS provided DT is a recipe for failure. > > -- > 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
