[PATCH V5 08/12] iot2050: Add script for signing artifacts

Simon Glass sjg at chromium.org
Mon Feb 13 05:26:43 CET 2023


Hi Jan,

On Tue, 7 Feb 2023 at 11:39, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Jan,
>
> On Tue, 7 Feb 2023 at 09:45, Jan Kiszka <jan.kiszka at siemens.com> wrote:
> >
> > On 07.02.23 16:28, Simon Glass wrote:
> > > Hi Jan,
> > >
> > > On Mon, 6 Feb 2023 at 04:57, Jan Kiszka <jan.kiszka at siemens.com> wrote:
> > >>
> > >> On 06.02.23 11:47, Jan Kiszka wrote:
> > >>> On 04.02.23 23:26, Simon Glass wrote:
> > >>>> Hi Jan,
> > >>>>
> > >>>> On Fri, 3 Feb 2023 at 23:35, Jan Kiszka <jan.kiszka at siemens.com> wrote:
> > >>>>>
> > >>>>> On 03.02.23 19:51, Tom Rini wrote:
> > >>>>>> On Fri, Feb 03, 2023 at 01:26:37PM +0100, Jan Kiszka wrote:
> > >>>>>>
> > >>>>>>> From: Jan Kiszka <jan.kiszka at siemens.com>
> > >>>>>>>
> > >>>>>>> There are many ways to get a signed firmware for the IOT2050 devices,
> > >>>>>>> namely for the parts under user-control. This script documents one way
> > >>>>>>> of doing it, given a signing key. Augment the board documentation with
> > >>>>>>> the required procedure around it.
> > >>>>>>>
> > >>>>>>> Signed-off-by: Jan Kiszka <jan.kiszka at siemens.com>
> > >>>>>> [snip]
> > >>>>>>> +# currently broken in upstream
> > >>>>>>> +#source/tools/binman/binman replace -i flash.bin -f fit at 0x380000.fit fit at 0x380000
> > >>>>>>> +dd if=fit at 0x380000.fit of=flash.bin bs=$((0x1000)) seek=$((0x380000/0x1000)) conv=notrunc
> > >>>>>>
> > >>>>>> Is that still a true comment?
> > >>>>>>
> > >>>>>
> > >>>>> binman: Node '/fit at 0x380000/images/u-boot': Offset 0x0 (0) size 0xb8870
> > >>>>> (755824) is outside the section '/fit at 0x380000' starting at 0x0 (0) of
> > >>>>> size 0x400 (1024)
> > >>>>>
> > >>>>> And for the second call:
> > >>>>>
> > >>>>> binman: Node '/fit at 0x380000': Replacing sections is not implemented yet
> > >>>>
> > >>>> I sent a patch to implement that.
> > >>>>
> > >>>> I'm not quite sure if this resolves the first problem, too. If not,
> > >>>> can you please provide a binman test for the case you need, or
> > >>>> instructions on how to cause the failure?
> > >>>
> > >>> Instructions to reproduce are basically
> > >>>  - apply this series
> > >>>  - build flash.bin according to doc/board/siemens/iot2050.rst
> > >>>  - drop the dd calls and activate binman in this signing script
> > >>>  - run it
> > >>>
> > >>> But I'll try your patch ASAP on my setup.
> > >>
> > >> Still left with
> > >>
> > >> binman: Node '/fit at 0x380000/images/u-boot': Offset 0x0 (0) size 0xb8928
> > >> (756008) is outside the section '/fit at 0x380000' starting at 0x0 (0) of
> > >> size 0x400 (1024)
> > >>
> > >> and
> > >>
> > >> binman: 'NoneType' object has no attribute 'props'
> > >>
> > >> That was for the second call of binman (source/tools/binman/binman
> > >> replace -i flash.bin -f fit at 0x380000.fit fit at 0x380000). The "not
> > >> implemented messages is gone.
> > >>
> > >> I've switched back to dd for the first call, but that did not work yet.
> > >> So the message above indicates a relevant error.
> > >>
> > >> Jan
> > >
> > > I thought I was able to follow all the steps (gosh, so many blobs) but
> > > I got something different from the first 'binman' call in your script.
> > >
> > > binman: Error 1 running 'mkimage -t -F
> > > /tmp/binman.l_xl69mi/fit at 0x380000.fit': mkimage: verify_header failed
> > > for FIT Image support with exit code 1
> > >
> > > I will take a look at that...it is trying to rebuild the FIT and it
> > > should not. It is another case of rebuilding sections that I didn't
> > > think of.
> > >
> > > But actually, you need to create a new entry type for your signing
> > > scheme. It looks like the signature is created by openssl and (rather
> > > than putting it in a separate file) it creates a new file containing
> > > both the signature and the file contents. That is a bit of a pain, but
> > > can be made to work.
> > >
> > > Basically you need a new entry type (of which the FIT is a child) that
> > > gets the contents of its child, signs it and returns that as the
> > > contents. You can see vblock for an example, and
> > > collection_contents_to_file(). Let me know if you want me to create an
> > > example.
> > >
> > > The way it should work is that you run binman once (as part of the
> > > U-Boot build) and it produces a final image. No messing about with
> > > scripts, etc. In this case it looks like the key.pem file should be an
> > > input to your new entry type.
> > >
> > > Using binman replace to sign something later is fine, but it is not
> > > the intended use. Binman is supposed to be a single-pass image
> > > builder.
> >
> > I strongly suspect we will need split build/sign also in the future
> > because those steps are generally separate in corporate production envs.
> > Maybe even 3 steps: assemble, extract hashes that should be signed and
> > embed signatures of those in the end.
>
> Yes I'm sure you are right, that's what I would expect. There is a
> 'binman sign' command coming[1] so I hope we can use that to make it
> easier, too.
>
> Still, we must have a single-step build in U-Boot, so we do need a new
> entry type. Let me know if you want me to hack up something as a
> starting point.

Please see here:

https://github.com/sjg20/u-boot/tree/for-jan

There is an entry type to create an x509 certificate, which I think it
part of what you are trying to do in your shell script.

Please take a look and see what you think.

The problem with the 'binman replace' command in the script is that it
seems to be overwriting the fdtmap. I am not sure why but will take a
look.

In any case, we should not be using the script, so let's try to get
the binman description complete for your board, so it contains all the
steps.

Regards,
Simon


>
> >
> > >
> > > Since we get different results, I suggest pushing a tree somewhere, in
> > > case something is different with the patches.
> >
> > Tree is already at https://github.com/siemens/u-boot/commits/jan/iot2050
> >
> > Jan
> >
> > --
> > Siemens AG, Technology
> > Competence Center Embedded Linux
> >
>
> Regards,
> Simon
>
> [1] https://patchwork.ozlabs.org/project/uboot/list/?series=291386&state=*


More information about the U-Boot mailing list