[PATCH 00/16] tools: Add support for signing devicetree blobs
Simon Glass
sjg at chromium.org
Thu Nov 25 01:12:12 CET 2021
Hi François,
On Sat, 13 Nov 2021 at 11:53, François Ozog <francois.ozog at linaro.org> wrote:
>
> 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.
I think UEFI is making things very complicated. If we define a
standard boot flow we should not need grub.
U-Boot already supports FIT so we don't have a problem there.
Since FIT is a container format, and UEFI supports other container
formats (capsule update for example), there is no obvious
philosophical reason why UEFI should not support FIT.
Anyway, at least you can understand why I sent this patch.
Regards,
SImon
>>
>>
>> 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