Hi Jan, On Tue, 9 Nov 2021 at 23:44, Jan Kiszka <jan.kis...@siemens.com> wrote: > > On 10.11.21 01:58, Simon Glass wrote: > > Hi Jan, > > > > On Tue, 9 Nov 2021 at 03:07, Jan Kiszka <jan.kis...@siemens.com> wrote: > >> > >> On 09.11.21 10:37, Roman Kopytin wrote: > >>> Can we have discussion with code lines? For me it is not very clear, > >>> because it isn't my code. > >>> > >> > >> Please do not top-post. > >> > >>> -----Original Message----- > >>> From: Jan Kiszka <jan.kis...@siemens.com> > >>> Sent: Tuesday, November 9, 2021 12:17 PM > >>> To: Roman Kopytin <roman.kopy...@kaspersky.com>; u-boot@lists.denx.de; > >>> Rasmus Villemoes <rasmus.villem...@prevas.dk> > >>> Subject: Re: [PATCH 0/2] RFC: add fdt_add_pubkey tool > >>> > >>> 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). > >>> > >>> Jan > >>> > >>> [1] > >>> https://lore.kernel.org/u-boot/20210928085651.619892-1-rasmus.villem...@prevas.dk/ > >>> > >>> -- > >>> Siemens AG, T RDA IOT > >>> Corporate Competence Center Embedded Linux > >>> > >> > >> For what would you like to have code? The kconfig addition? > >> > >> diff --git a/common/Kconfig.boot b/common/Kconfig.boot > >> index d3a12be228..a9ed4d4ec4 100644 > >> --- a/common/Kconfig.boot > >> +++ b/common/Kconfig.boot > >> @@ -279,6 +279,14 @@ config SPL_FIT_GENERATOR > >> > >> endif # SPL > >> > >> +config FIT_SIGNATURE_PUB_KEYS > >> + string "Public keys to use for FIT image verification" > >> + depends on FIT_SIGNATURE || SPL_FIT_SIGNATURE > >> + help > >> + Public keys, or certificate files to extract them from, that > >> shall > >> + be used to verify signed FIT images. The keys will be embedded > >> into > >> + the control device tree of U-Boot. > >> + > >> endif # FIT > >> > >> config LEGACY_IMAGE_FORMAT > >> > >> > >> But note that we are in a design discussion here, and I'm at least > >> reluctant to code up n-versions without having some common idea where > >> things should move. > > > > I'm not sure we want this built into U-Boot. I see signing of a > > firmware image as a final step, with the keys being added then, e.g. > > by binman. > > This is not signing, this in embedding public key information into build > artifacts before they can be signed. As pointed out in my other thread, > not having an embedding feature is a major drawback of the current > workflow. It easily forces you to rebuild existing build flows in > out-of-tree scripts.
The public key is not needed for signing to work, right? I don't understand what you are getting at here. If you want to add the public key to the image before it is signed, that's fine. I just don't understand why you want to do that. Why not have the signer do everything? Regards, Simon
