Hi Jan, On Wed, 10 Nov 2021 at 09:48, Jan Kiszka <jan.kis...@siemens.com> wrote: > > On 10.11.21 17:31, Simon Glass wrote: > > 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? > > A) Because sensitive signing environments will not run arbitrary logic. > They will hand out the public key, but they may not give you the > chance to run mkimage with the private key, like you would do during > development.
That's OK, so long as there is a way to get the data to be signed in, and the public key and signature out. > > B) It avoids having to run the signing process in a specific order > because it already embeds the public key during build, thus > generates everything that shall be signed upfront. The public key is not signed though. Whether it is present at the start or not is not important. Regards, Simon
