[PATCH 00/16] tools: Add support for signing devicetree blobs
François Ozog
francois.ozog at linaro.org
Sat Nov 13 19:53:44 CET 2021
Hi Simon
Le sam. 13 nov. 2021 à 14:57, Simon Glass <sjg at chromium.org> a écrit :
> Hi Heinrich,
>
> On Sat, 13 Nov 2021 at 04:57, Heinrich Schuchardt <xypron.glpk at gmx.de>
> wrote:
> >
> >
> >
> > On 11/13/21 04:30, Simon Glass wrote:
> > > 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.
> >
> > The problem with FIT is that other firmware like EDK II does not support
> it.
> >
> > Why do you expect those people to like your new tool better?
>
> I believe the EDK decision is not so much that it *does* not support
> FIT, which is after all not a lot of code, but that it *should* not.
> If I have that wrong, please let me know.
>
UEFI (EDK2 and now U-Boot) design choice is that it does not include *any*
technologies for OS: UEFI launches an OS loader that know about those.
A possible way to introduce a FIT is by adding a protocol that can register
a vendor media file , assign a UUID to a FIT. Add support for this in the
UEFI stub of the kernel.
Another way would be a minimalistic UEFI app that will fetch the second
parameter as a FIT. The FIT format parsing code is only in this
minimalistic loader. U-Boot can play this role based on your efforts to
have U-Boot as UEFI application.
You could also promote FIT in the systemd-boot UeFi application. I believe
this is a very good option BTW.
>
> The goal here is to support signing in an FDT without FIT. I believe
> EDK supports FDT, at least.
>
> >
> > >
> > >>
> > >>>
> > >>>
> > >>> 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 question was:
> >
> > How do you protect the private key used by Linux to sign the FIT image
> > with the updated initrd generated by intramfs-tools?
>
> Well, if it is a FIT we can add a seperate signature at the time the
> initramfs-tools runs. It does support multiple signatures. If that is
> not suitable I am sure something else can be devised. What are the
> constraints / requirements?
>
> Regards,
> Simon
>
> >
> > Best regards
> >
> > Heinrich
> >
> > >
> > >>
> > >>>
> > >>> 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.
> > >
> > >>
> > >>> 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).
> > >>
> > >> 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
More information about the U-Boot
mailing list