binman replace broken? (was: Re: [PATCH 0/2] RFC: add fdt_add_pubkey tool)

[Jan Kiszka]

On 10.11.21 08:20, Jan Kiszka 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.
> 
> 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?
> 

Well, too quick: "binman replace" writes everything into a temporary
directory, including the updated image - and then deletes this directory
on exit. So the original image will not be updated, and the update is lost.

I tried to quickly fix it by adding a rename before FinaliseOutputDir,
but it feels like I'm working against the design of the internal
interfaces here.

Jan

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