[PATCH 0/2] RFC: add fdt_add_pubkey tool

[Jan Kiszka]

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.

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.

But one after the other.

Jan

-- 
Siemens AG, T RDA IOT
Corporate Competence Center Embedded Linux