[PATCH 0/2] RFC: add fdt_add_pubkey tool

[Simon Glass]

Hi Jan,

On Wed, 10 Nov 2021 at 00:20, Jan Kiszka <jan.kiszka at siemens.com> wrote:
>
> On 10.11.21 07:55, Jan Kiszka wrote:
> > On 10.11.21 01:58, Simon Glass wrote:
> >> Hi,
> >>
> >> On Tue, 9 Nov 2021 at 02:17, Jan Kiszka <jan.kiszka at siemens.com> wrote:
> >>>
> >>> 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).
> >>
> >> Also please take a look at binman which is designed to handle create
> >> (or later updating from Yocto) the devicetree or firmware image.
> >>
> >
> > Yes, binman is another problem area, but not for the public key
> > injection, rather for permitting to sign fit images that are described
> > for binman (rather than for mkimage). I'm currently back to dd for
> > signing the U-Boot container in
> > arch/arm/dts/k3-am65-iot2050-boot-image.dtsi, or I would have to split
> > that FIT image description from that file - both not optimal.

Well I don't think binman supports that at present, or at least I'm
not sure what it would do. We don't have a test case for it. If you
have an idea for how it should work, please send some ideas and I can
look at it.

>
> OK, this can already be optimized with "binman replace" - once I
> understood where fdtmap can go and where not. Why no support for using
> map files?

The fdtmap provides enough information to extract anything from the
image and regenerate/replace things.

What is a map file?

>
> Jan
>
> >
> > And another area: Trust centers that perform the signing (and only that)
> > usually do not support random formats and workflows but just few common
> > ones, e.g. x509. It would be nice to have a way to route out the payload
> > (hashes etc.) that mkimage would sign, ideally into a standard signing
> > request, and permit to inject the resulting signature at the right
> > places into the FIT image.

Well that needs to be provided somewhere. It should be fairly easy to
get Binman to do this, so long as the image description has info about
what is being signed.

> >
> > But one after the other.

Possibly, but sometimes it is best to design things up-front.

Regards,
Simon