On Tue, 4 Jun 2019 at 10:57, Ard Biesheuvel <[email protected]> wrote:
> > > On Tue, 4 Jun 2019 at 16:52, Francois Ozog <[email protected]> > wrote: > >> >> >> 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? >> >> > Yes, we are. And this is a battle I have been fighting for years, but the > distros as well as the silicon vendors are only interested in Microsoft > owning all the secure boot signing keys, as they do on x86. > > 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. >> >> > Yes, that makes sense. But the problem is that UEFI secure boot does not > support this model. An image is considered valid if it authenticates > against any of the keys in db. And any key in KEK can sign updates to db > and dbx. And today's current practice is to include Microsoft keys in both > KEK and db. > > Only shim<arch>.efi is Microsoft signed. So we shold be clear to sign SecureBoot without Shim, booting directly grub<arch>.efi for instance. > I have argued time and time again that this is entirely broken as a > security model. Any db update that Microsoft has ever signed can be applied > to my brand new arm64 system (unless it has been blacklisted explicitly, > and my vendor has bothered to ship with an up to date dbt) > > I am perfectly happen to reopen that debate as well, by the way :-) > > > -- 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
