[PATCH 2/3] tools: add fdt_add_pubkey

[Alex Kiernan]

On Tue, Feb 11, 2020 at 10:22 AM Rasmus Villemoes
<rasmus.villemoes at prevas.dk> wrote:
>
> On 11/02/2020 10.54, Alex Kiernan wrote:
> > On Tue, Feb 11, 2020 at 9:49 AM Rasmus Villemoes
> > <rasmus.villemoes at prevas.dk> wrote:
> >>
> >> Having to use the -K option to mkimage to populate U-Boot's .dtb with the
> >> public key while signing the kernel FIT image is often a little
> >> awkward. In particular, when using a meta-build system such as
> >> bitbake/Yocto, having the tasks of the kernel and U-Boot recipes
> >> intertwined, modifying deployed artifacts and rebuilding U-Boot with
> >> an updated .dtb is quite cumbersome. Also, in some scenarios one may
> >> wish to build U-Boot complete with the public key(s) embedded in the
> >> .dtb without the corresponding private keys being present on the same
> >> build host.
> >>
> >
> > Have you started looking at the required bitbake pieces? You're
> > definitely dealing with a piece of pain that I'd like resolved!
>
> Not really, but I know that something like this is a necessary first
> part - and I'm glad to know I'm not the only one struggling with this.
>
> For now I've come to the conclusion that kernel-fitimage.bbclass is not
> worth the trouble (for example, I need to create two different fit
> images with different initramfs, but a fit image without initramfs is
> pointless in my case, and there's no way to use kernel-fitimage.bbclass
> for that), so I just set KERNEL_IMAGETYPE to vmlinux, then have my own
> extra tasks doing the objcopy -O binary, gzip, and mkimage the different
> fit images I need.
>

kernel-fitimage is a nightmare... every time someone touches it the
risk of it breaking for someone else is pretty high. FWIW my flow
through it is just kernel (no initramfs), DTBs and configurations,
with keys pre-embedded in U-Boot, so avoiding the loop back through
that otherwise happens. But I could do with the ability to compose
configurations in it, which isn't easy with it today.

I suspect leaving kernel-fitimage to one side and starting again (with
tests) has a lot of merit!

> [I'm also thinking that adding a companion tool for doing the signing
> part might make sense at some point - it's somewhat counter-intuituve
> that the .its contains some of the information (base name of key and
> algorithm - mkimage currently just segfaults if key-name-hint is
> accidentally omitted from the .its), while mkimage needs to be fed with
> another part (directory holding the keys).]
>
> Rasmus



--
Alex Kiernan