Hi Jan,
On Wed, 10 Nov 2021 at 13:49, Jan Kiszka jan.kiszka@siemens.com wrote:
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@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.
If you want to see how things work, check out ftest.py which has all the tests. If there is a test for it, it probably works. If not, it might not.
Regards, SImon