On 6/4/19 4:37 PM, Ard Biesheuvel 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. > > 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.
You are a making a very valid point here. A Linux distribution typically comes with dozens of device trees. Currently U-Boot uses the filename to identify which is the correct device tree. And then Linux trusts the firmware to have made the right choice. So in a process to validate external device trees there would be some content element (e.g. the model property) needed to be checked by the firmware besides a signature. Regards Heinrich > > 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? > >> 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. > _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
