[PATCH 00/16] tools: Add support for signing devicetree blobs

François Ozog francois.ozog at linaro.org
Sat Nov 13 19:41:31 CET 2021


Hi Simon

Le sam. 13 nov. 2021 à 14:57, Simon Glass <sjg at chromium.org> a écrit :

> Hi François,
> On Sat, 13 Nov 2021 at 03:18, François Ozog <francois.ozog at linaro.org>
> wrote:
> >
> > Hi Simon,
> >
> > Le sam. 13 nov. 2021 à 04:31, Simon Glass <sjg at chromium.org> a écrit :
> >>
> >> Hi Heinrich,
> >>
> >> On Fri, 12 Nov 2021 at 17:02, Heinrich Schuchardt <xypron.glpk at gmx.de>
> wrote:
> >> >
> >> >
> >> >
> >> > On 11/12/21 20:49, François Ozog wrote:
> >> > > Hi Simon
> >> > >
> >> > > Le ven. 12 nov. 2021 à 20:36, Simon Glass <sjg at chromium.org
> >> > > <mailto:sjg at chromium.org>> a écrit :
> >> > >
> >> > >     At present mkimage supports signing FITs, the standard U-Boot
> image
> >> > >     type.
> >> > >
> >> > >     Various people are opposed to using FIT since:
> >> > >
> >> > > just to be sure: I am not one of those.
> >> > >
> >> > >
> >> > >     a) it requires adding support for FIT into other bootloaders,
> notably
> >> > >         UEFI
> >> > >
> >> > > whatever happens to FIT is entirely orthogonal to U-Boot UEFI
> subsystem.
> >> > > FIT can evolve,  U-Boot UEFI does not have to change.
> >> >
> >> > We already can create signed FIT images containing a UEFI binary and a
> >> > devcie-tree and launch the FIT image with the bootm command.
> >> >
> >> > Cf.
> >> > CONFIG_BOOTM_EFI
> >> > test/py/tests/test_efi_fit.py
> >> > doc/usage/bootefi.rst
> >> >
> >> > Simon, what are you missing?
> >>
> >> Some people don't want to use FIT.
> >>
> >> >
> >> > >
> >> > >
> >> > >     b) it requires packaging a kernel in this standard U-Boot
> format,
> >> > >     meaning
> >> > >         that distros must run 'mkimage' and deal with the kernel
> and initrd
> >> > >         being inside a FIT
> >> >
> >> > U-Boot tools are contained in distros like Debian and Ubuntu.
> >> > Package flash-kernel uses a script in /etc/initramfs/post-update.d/
> for
> >> > a similar purpose. The same hook directory can be used to create a FIT
> >> > image with a simple bash script.
> >> >
> >> > Why do we need a new tool for signing device-trees?
> >> >
> >> > The real problem to solve is the protection of the private key used
> for
> >> > signing any file containing an initrd.
> >>
> >> Well FIT already solves that one. Either FIT is not being used, in
> >> which case this series is useful, or it is being used, in which case
> >> the initrd problem is solved.
> >>
> >> >
> >> > >
> >> > >     The kernel and initrd can be dealt with in other ways. But
> without FIT,
> >> >
> >> > How can the initrd be checked without FIT?
> >>
> >> I don't know. Please check with the EFI people.
> >
> > Ilias has made a proposal to “measure” files that do not have signatures
> until files include signature.
>
> OK
>
> >>
> >>
> >> >
> >> > >     we have no standard way of signing and grouping FDT files.
> Instead
> >> > >     we must
> >> > >     include them in the distro as separate files.
> >> > >
> >> > >     In particular, some sort of mechanism for verifying FDT files
> is needed.
> >> > >     One option would be to tack a signature on before or after the
> file,
> >> > >     processing it accordingly. But due to the nature of the FDT
> binary
> >> > >     format,
> >> > >     it is possible to embed a signature inside the FDT itself,
> which is very
> >> > >     convenient.
> >> > >
> >> > >     This series provides a tool, fdt_sign, which can add a
> signature to an
> >> > >     FDT. The signature can be checked later, preventing any change
> to
> >> > >     the FDT,
> >> > >     other than in permitted nodes (e.g. /chosen).
> >> >
> >
> > Shouldn’t devicetree.org and kernel.org folks involved in this DT
> signing effort ? I believe there are parrallel efforts in this area. Or is
> it a private <u-boot FDT sign>? in that case, they do not need to be
> involved. Depending on the case, you may want to split the patch series in
> a number of chunks.
>
> Yes indeed these people should be involved, but I also think that
> interested parties should be part of the boot-architecture effort. The
> meeting notes where this tool was discussed are here:
>
>
> https://lists.linaro.org/pipermail/boot-architecture/2021-October/001955.html
>
> My slides are available there, too.
>
> Here is what I have done so far: I sent a v4 series to
> devicetree-compiler a week ago with the fdt_region and fdtgrep parts.
> Rob and Bill are copied on this series, as you can see. I was not sure
> about sending U-Boot patches to the boot-architecture list, but I will
> cover it in a future meeting.
>
> But if there are others that should be copied, please feel free to add
> them, or point me to them.
>
Sorry. I missed those. Now the reference is made that’s good.

>
> Regards,
> Simon
>
>
> >>
> >>
> >> > I am not aware of any standard defining which nodes may be changed in
> >> > the FDT fixup and which may not be changed.
> >> >
> >> > How can we discover which nodes were excluded from the signature after
> >> > the signature?
> >>
> >> There is no way at present. I decided against adding a list of signed
> >> nodes. We can of course add whatever is useful here.
> >>
> >> >
> >> > >
> >> > >     This series also provides a fdt_check_sign tool, used to check
> >> > >     signatures.
> >> > >
> >> > >     Both of these tools are stand-alone do not require mkimage or
> FIT.
> >> > >
> >> > >     As with FIT signing, multiple signatures are possible, but in
> this case
> >> > >     that requires that fit_sign be called once for each signature.
> To
> >> > >     make the
> >> > >     check fail if a signature does not match, it should be marked as
> >> > >     'required' using the -r flag to fdt_sign.
> >> > >
> >> > >     Run-time support for checking FDT signatures could be added to
> U-Boot
> >> > >     fairly easily, but needs further discussion as the correct
> plumbing
> >> > >     needs
> >> > >     to be determined.
> >> > >
> >> > >     For now there is absolutely no configurability in the signature
> >> > >     mechanism.
> >> >
> >> > I would have expected a description of what a signature looks like. I
> >> > don't wont to reverse engineer your patches.
> >> >
> >> > Please, describe this in doc/develop/ and in this cover-letter.
> >>
> >> It is the same format as the FIT signature, an RSA signature. See here:
> >>
> >>
> https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/signature.txt#L162
> >>
> >> >
> >> > This series should have been sent as RFC.
> >>
> >> The last time I did that it disappeared without trace. You can of
> >> course make comments on any series I send.
> >>
> >> Regards,
> >> Simon
> >>
> >> >
> >> > Best regards
> >> >
> >> > Heinrich
> >> >
> >> > >     It would of course be possible to adjust which nodes are
> signed, as is
> >> > >     done for FIT, but that needs further discussion also. The
> omission
> >> > >     of the
> >> > >     /chosen node is implemented in h_exclude_nodes() like this:
> >> > >
> >> > >         if (type == FDT_IS_NODE) {
> >> > >            /* Ignore the chosen node as well as /signature and
> subnodes */
> >> > >            if (!strcmp("/chosen", data) || !strncmp("/signature",
> data, 10))
> >> > >               return 0;
> >> > >         }
> >> > >
> >> > >     Man pages are provided with example usage of the tools. Use
> this to view
> >> > >     them:
> >> > >
> >> > >         man -l doc/fdt_check_sign.1
> >> > >
> >> > >     This series also includes various clean-ups noticed along the
> way,
> >> > >     as well
> >> > >     as refactoring to avoid code duplication with the new tools. The
> >> > >     last four
> >> > >     patches are the new code.
> >> > >
> >> > >     This series is available at u-boot-dm/fdt-sign-working :
> >> > >
> >> > >
> https://source.denx.de/u-boot/custodians/u-boot-dm/-/tree/fdt-sign-working
> >> > >     <
> https://source.denx.de/u-boot/custodians/u-boot-dm/-/tree/fdt-sign-working
> >
> >> > >
> >> > >
> >> > >     Simon Glass (16):
> >> > >        rsa: Add debugging for failure cases
> >> > >        fit_check_sign: Update help to mention the key is in a dtb
> >> > >        tools: Move copyfile() into a common file
> >> > >        tools: Avoid leaving extra data at the end of copied files
> >> > >        tools: Improve comments in signing functions
> >> > >        tools: Drop unused name in image-host
> >> > >        tools: Avoid confusion between keys and signatures
> >> > >        tools: Tidy up argument order in fit_config_check_sig()
> >> > >        tools: Pass the key blob around
> >> > >        image: Return destination node for add_verify_data() method
> >> > >        tools: Pass public-key node through to caller
> >> > >        tools: mkimage: Show where signatures/keys are written
> >> > >        tools: Add a new tool to sign FDT blobs
> >> > >        tools: Add a new tool to check FDT-blob signatures
> >> > >        test: Add a test for FDT signing
> >> > >        tools: Add man pages for fdt_sign and fdt_check_sign
> >> > >
> >> > >       MAINTAINERS                      |   7 +
> >> > >       boot/image-fit-sig.c             | 151 +++++++++----
> >> > >       boot/image-fit.c                 |  12 +-
> >> > >       common/spl/spl_fit.c             |   3 +-
> >> > >       doc/fdt_check_sign.1             |  74 +++++++
> >> > >       doc/fdt_sign.1                   | 111 ++++++++++
> >> > >       include/image.h                  |  80 ++++++-
> >> > >       include/u-boot/ecdsa.h           |   5 +-
> >> > >       include/u-boot/rsa.h             |   5 +-
> >> > >       lib/ecdsa/ecdsa-libcrypto.c      |   4 +-
> >> > >       lib/rsa/rsa-sign.c               |   5 +-
> >> > >       lib/rsa/rsa-verify.c             |  13 +-
> >> > >       test/py/tests/test_fdt_sign.py   |  83 ++++++++
> >> > >       test/py/tests/test_vboot.py      |  21 +-
> >> > >       test/py/tests/vboot/sign-fdt.dts |  23 ++
> >> > >       test/py/tests/vboot_comm.py      |  22 ++
> >> > >       tools/Makefile                   |  10 +-
> >> > >       tools/fdt-host.c                 | 353
> +++++++++++++++++++++++++++++++
> >> > >       tools/fdt_check_sign.c           |  85 ++++++++
> >> > >       tools/fdt_host.h                 |  46 ++++
> >> > >       tools/fdt_sign.c                 | 210 ++++++++++++++++++
> >> > >       tools/fit_check_sign.c           |   4 +-
> >> > >       tools/fit_common.c               |  69 ++++++
> >> > >       tools/fit_common.h               |  23 ++
> >> > >       tools/fit_image.c                |  59 +-----
> >> > >       tools/image-fdt-sig.c            | 254 ++++++++++++++++++++++
> >> > >       tools/image-host.c               | 155 +++++++++++---
> >> > >       tools/imagetool.h                |   4 +
> >> > >       tools/mkimage.c                  |   4 +
> >> > >       29 files changed, 1714 insertions(+), 181 deletions(-)
> >> > >       create mode 100644 doc/fdt_check_sign.1
> >> > >       create mode 100644 doc/fdt_sign.1
> >> > >       create mode 100644 test/py/tests/test_fdt_sign.py
> >> > >       create mode 100644 test/py/tests/vboot/sign-fdt.dts
> >> > >       create mode 100644 test/py/tests/vboot_comm.py
> >> > >       create mode 100644 tools/fdt-host.c
> >> > >       create mode 100644 tools/fdt_check_sign.c
> >> > >       create mode 100644 tools/fdt_sign.c
> >> > >       create mode 100644 tools/image-fdt-sig.c
> >> > >
> >> > >     --
> >> > >     2.34.0.rc1.387.gb447b232ab-goog
> >> > >
> >> > > --
> >> > >
> >> > > François-Frédéric Ozog | /Director Business Development/
> >> > > T: +33.67221.6485
> >> > > francois.ozog at linaro.org <mailto:francois.ozog at linaro.org> |
> Skype: ffozog
> >> > >
> >> > >
> >
> > --
> > François-Frédéric Ozog | Director Business Development
> > T: +33.67221.6485
> > francois.ozog at linaro.org | Skype: ffozog
> >
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog


More information about the U-Boot mailing list