[PATCH 0/2] RFC: add fdt_add_pubkey tool

[Simon Glass]

Hi Jan,

On Wed, 10 Nov 2021 at 09:49, Jan Kiszka <jan.kiszka at siemens.com> wrote:
>
> On 10.11.21 17:31, Simon Glass wrote:
> > 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?
>
> *.map, e.g. image.map? Also generated by many binmap <cmd> -m?

Using map files for what? Do you mean passing it to Binman in lieu of
an in-image fdtmap? If so, they are not equivalent. The map is just a
simple text output of offsets and sizes. The fdtmap contains the full
image description.

>
> >
> >>
> >> 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.
>
> I would assume that it has to have that information, already to use
> mkimage on it or its parts.

Well, at present the information is there but Binman does not fully
parse the mkimage subnodes. E.g. it doesn't look to see what things
are signed/hashed. It just runs mkimage. If we want to output the hash
for signing, we would need to implement that somewhere. Binman could
do this after the image is build, i.e. look at the various signature
nodes, hash the appropriate data and write out an 'instructions' file
in a suitable format.

>
> >
> >>>
> >>> But one after the other.
> >
> > Possibly, but sometimes it is best to design things up-front.
> >
>
> True as well.

Regards,
Simon