On Tue, 4 Jun 2019 at 10:37, Ard Biesheuvel <[email protected]> wrote:
> On Tue, 4 Jun 2019 at 16:29, Heinrich Schuchardt <[email protected]> > wrote: > > > > > > > > On 6/4/19 4:20 PM, Ard Biesheuvel wrote: > > > On Tue, 4 Jun 2019 at 16: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. > > >> > > > > > > Of course. But that does not mean it should be the job of UEFI secure > > > boot to do so. > > > > > > > For me validating the device-tree means that U-Boot checks a signature > > added to the device-tree. It is just the same type ofprocess as the one > > we will do in UEFI secure boot when loading an application like GRUB or > > Linux. > > > > Even if we use the same algorithms to authenticate a DT as we use to > authenticate parts of the OS, conflating the two is a dangerous and > slippery slope. The industry today expresses a strong preference > towards putting all the security eggs in a single basket, and make > Microsoft the owner of all keys relating to secure boot. > > Aren't we talking about Arm systems that do not need Microsoft keys? This means that if we standardize secure boot as the means to > authenticate DT to the firmware, this may lead to a situation where I > can load a DT for a different but similar SoC into my system (given > that they are all signed by Microsoft), and possibly circumvent > security features since the GPIOs are not wired the same. > > So now we have two classes of images, platform and OS. Do we add > separate keyrings? Do we add metadata? What else do we need to add > beyond what the UEFI spec defines to support this model? > > EL3 software (trustedfirmware for instance) validates untrusted firmware, and probably DTs. Or is U-Boot a consummer of TF provided DT? Does U-Boot provide a DT to OS? I had a discussion with Loic from ST (added) that he sees multiple keys for different parts of the boot. > Verification of the device tree is a necessary part of secure booting. > > But as it is not in the UEFI spec up to now you may be inclined not to > > call it "UEFI" secure boot. > > > > In my opinion, we should leave it up to the platform to solve this, > and not standardize it in the context of UEFI. If u-boot wants to load > DT from a file and authenticate it, that is perfectly fine, but don't > conflate it with authenticating the OS. > -- 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
