Hi Jan, On Wed, 10 Nov 2021 at 13:51, Jan Kiszka <jan.kis...@siemens.com> wrote: > > On 10.11.21 20:36, Simon Glass wrote: > > 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. > > The public key is signed when it is placed into an image that is signed. > That is the case, e.g., when injecting it into the SPL control FDT and > then signing the SPL image. Or when injecting it into the main control > FDT and signing U-Boot proper afterwards.
Ah OK, so it is signed along with everything else. Regards, Simon > > Jan > > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux
