[PATCH 0/2] RFC: add fdt_add_pubkey tool

Simon Glass sjg at chromium.org
Wed Nov 10 01:58:11 CET 2021


Hi François,

On Tue, 9 Nov 2021 at 05:43, François Ozog <francois.ozog at linaro.org> wrote:
>
> Hi
>
> as we are in design discussions, I would promote the idea of not pushing
> non hardware related things in the DTB that is passed to the kernel.
> Is your use case to allow U-Boot to verify the kernel's signature ?
> Why not putting it into an environment variable?

We have been through this many times but I'll state it again. U-Boot
makes use of the devicetree for configuration information, including
public keys, etc.

It does not belong anywhere else.

http://patchwork.ozlabs.org/project/uboot/patch/20211026002344.405160-3-sjg@chromium.org/


>
> If your use case is on Arm or RISC-V, both environments are working heavily
> to make https://arm-software.github.io/ebbr/ standard available on a large
> number of boards.
> This offers UEFI interface and SecureBoot (and later MeasuredBoot)
> services. For Arm boards just check for SystemReady compliance.
> In this context, traditional UEFI secure variables are used to deal with
> certificates and hashes: PK, KEK, db...
> You can obviously do differently but you will be on your own to extend the
> chain of trust to IMA, secure containers (rooted down to hRoT) and other
> security facilities in the Linux side.
> Could you describe your use case in more details?
>

That feature does not use FIT images, nor U-Boot's verified boot.

Regards,
Simon


> On Tue, 9 Nov 2021 at 11:07, Jan Kiszka <jan.kiszka at siemens.com> wrote:
>
> > On 09.11.21 10:37, Roman Kopytin wrote:
> > > Can we have discussion with code lines? For me it is not very clear,
> > because it isn't my code.
> > >
> >
> > Please do not top-post.
> >
> > > -----Original Message-----
> > > From: Jan Kiszka <jan.kiszka at siemens.com>
> > > Sent: Tuesday, November 9, 2021 12:17 PM
> > > To: Roman Kopytin <Roman.Kopytin at kaspersky.com>; u-boot at lists.denx.de;
> > Rasmus Villemoes <rasmus.villemoes at prevas.dk>
> > > Subject: Re: [PATCH 0/2] RFC: add fdt_add_pubkey tool
> > >
> > > On 08.11.21 16:28, Roman Kopytin wrote:
> > >> In order to reduce the coupling between building the kernel and
> > >> U-Boot, I'd like a tool that can add a public key to U-Boot's dtb
> > >> without simultaneously signing a FIT image. That tool doesn't seem to
> > >> exist, so I stole the necessary pieces from mkimage et al and put it
> > >> in a single .c file.
> > >>
> > >> I'm still working on the details of my proposed "require just k out
> > >> these n required keys" and how it should be implemented, but it will
> > >> probably involve teaching this tool a bunch of new options. These
> > >> patches are not necessarily ready for inclusion (unless someone else
> > >> finds fdt_add_pubkey useful as is), but I thought I might as well send
> > >> it out for early comments.
> > >
> > > I'd also like to see the usage of this hooked into the build process.
> > >
> > > And to my understanding of [1], that approach will provide a feature
> > that permits hooking with the build but would expect the key as dtsi
> > fragment. Can we consolidate the approaches?
> > >
> > > My current vision of a user interface would be a Kconfig option that
> > takes a list of key files to be injected. Maybe make that three lists, one
> > for "required=image", one for "required=conf", and one for optional keys
> > (if that has a use case in practice, no idea).
> > >
> > > Jan
> > >
> > > [1]
> > >
> > https://lore.kernel.org/u-boot/20210928085651.619892-1-rasmus.villemoes@prevas.dk/
> > >
> > > --
> > > Siemens AG, T RDA IOT
> > > Corporate Competence Center Embedded Linux
> > >
> >
> > For what would you like to have code? The kconfig addition?
> >
> > diff --git a/common/Kconfig.boot b/common/Kconfig.boot
> > index d3a12be228..a9ed4d4ec4 100644
> > --- a/common/Kconfig.boot
> > +++ b/common/Kconfig.boot
> > @@ -279,6 +279,14 @@ config SPL_FIT_GENERATOR
> >
> >  endif # SPL
> >
> > +config FIT_SIGNATURE_PUB_KEYS
> > +       string "Public keys to use for FIT image verification"
> > +       depends on FIT_SIGNATURE || SPL_FIT_SIGNATURE
> > +       help
> > +         Public keys, or certificate files to extract them from, that
> > shall
> > +         be used to verify signed FIT images. The keys will be embedded
> > into
> > +         the control device tree of U-Boot.
> > +
> >  endif # FIT
> >
> >  config LEGACY_IMAGE_FORMAT
> >
> >
> > But note that we are in a design discussion here, and I'm at least
> > reluctant to code up n-versions without having some common idea where
> > things should move.
> >
> > Jan
> >
> > --
> > Siemens AG, T RDA IOT
> > Corporate Competence Center Embedded Linux
> >
>
>
> --
> 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