[RFC PATCH] binman: bintool: etype: Add support for ti-secure entry

Simon Glass sjg at chromium.org
Fri Mar 10 21:49:43 CET 2023 

Hi,

On Thu, 9 Mar 2023 at 21:35, Neha Malcom Francis <n-francis at ti.com> wrote:
>
> Hi Andrew, Simon
>
> On 01/03/23 22:41, Andrew Davis wrote:
> > On 2/28/23 9:10 AM, Simon Glass wrote:
> >> Hi Neha,
> >>
> >> On Tue, 28 Feb 2023 at 02:50, Neha Malcom Francis <n-francis at ti.com>
> >> wrote:
> >>>
> >>> Hi Simon,
> >>>
> >>> On 28/02/23 06:05, Simon Glass wrote:
> >>>> Hi Neha,
> >>>>
> >>>> On Fri, 24 Feb 2023 at 05:03, Neha Malcom Francis <n-francis at ti.com>
> >>>> wrote:
> >>>>>
> >>>>> core-secdev-k3 is the TI security development package provided for K3
> >>>>> platform devices. This tool helps sign bootloader images with the x509
> >>>>> ceritificate header.
> >>>>>
> >>>>> Signed-off-by: Neha Malcom Francis <n-francis at ti.com>
> >>>>> ---
> >>>>> This patch depends on
> >>>>> https://patchwork.ozlabs.org/project/uboot/patch/20230224115101.563729-1-n-francis@ti.com/
> >>>>> and on ongoing development in
> >>>>> https://git.ti.com/cgit/security-development-tools/core-secdev-k3
> >>>>>
> >>>>>    tools/binman/btool/tisecuretool.py            |  72 +++++++++++
> >>>>>    tools/binman/etype/ti_secure.py               | 114
> >>>>> ++++++++++++++++++
> >>>>>    tools/binman/ftest.py                         |  36 ++++++
> >>>>>    tools/binman/test/278_ti_secure_rom.dts       |  11 ++
> >>>>>    tools/binman/test/279_ti_secure.dts           |  11 ++
> >>>>>    .../binman/test/280_ti_secure_nofilename.dts  |  10 ++
> >>>>>    tools/binman/test/281_ti_secure_combined.dts  |  12 ++
> >>>>>    7 files changed, 266 insertions(+)
> >>>>>    create mode 100644 tools/binman/btool/tisecuretool.py
> >>>>>    create mode 100644 tools/binman/etype/ti_secure.py
> >>>>>    create mode 100644 tools/binman/test/278_ti_secure_rom.dts
> >>>>>    create mode 100644 tools/binman/test/279_ti_secure.dts
> >>>>>    create mode 100644 tools/binman/test/280_ti_secure_nofilename.dts
> >>>>>    create mode 100644 tools/binman/test/281_ti_secure_combined.dts
> >>>>
> >>>> Now that I see what you are doing, this it not quite the right way.
> >>>>
> >>>> See this hack-up of how you can call the openssl thing. Basically you
> >>>> should not have a shell script in the way, but instead make your
> >>>> bintool do it.
> >>>>
> >>>> https://github.com/sjg20/u-boot/commit/03c0d74f81106570b18d8e4fe7a3355bfeb0d5da#r100378804
> >>>>
> >>>> I suppose we can have an openssl bintool that others build on top of?
> >>>>
> >>>> Regards,
> >>>> Simon
> >>>>
> >>>>
> >>>
> >>> That is possible, maybe ti-secure extends from x509_cert etype so as to
> >>> support the TI specific certificate extensions. I'll start working on
> >>> this.
> >>>
> >>> However the patches I've sent support external production flow where
> >>> signing need not necessarily be carried out from U-Boot. An external
> >>> repo that acts as what is core-secdev-k3 here, would be the repo
> >>> responsible for signing.
> >>>
> >>> Could we find a way to combine both so as to support production flow
> >>> mandating an external agency, as well as a completely within U-Boot flow
> >>> using bintool? i.e. we modify ti-secure etype to be able to support both
> >>> external git repo/executable script signing as well as default signing
> >>> using openssl bintool.
> >>
> >> Yes that seems important.
> >>
> >> One option is to have binman emit some instructions on how to sign the
> >> image, perhaps a simple data format similar to an fdtmap, with a basic
> >> shell script plus whatever the etype provides. Then the signer can
> >> follow the instructions or run the script.
> >>
> >> Another option is to run binman on the signer and have it do the
> >> signing. Would that work?
> >>
> >
> > I'd like to keep the dependencies needed on the signing server as
> > minimal as possible. We do require the "u-boot-tools" package on
> > the key servers if folks want to re-package signed FIT images, so
> > if binman could be reasonably packaged in that package someday
> > it could be an option.

At present binman is packaged as binary-manager (with 'pip install').
Is that good enough? We could add it to u-boot-tools, perhaps, but I
have found that packing Python things together with non-Python things
seems to be tricky. We gave up with libfdt and ended up using a
separate package for pylibfdt.

> >
> > For now, if binman could generate the x509 file and leave it with the
> > other boot artifacts then if one needs to re-sign with real keys they
> > will only need to have openssl sign that cert and append to the image
> > on the key server, that is simple enough document.

I sent a patch to add x509 cert using the openssl tool[1]. If there is
more needed, can you take a look or let me know what is missing?

> >
> > The more difficult part is in re-packaging these signed images.
> > Our security tools already have a tool to disasemble a FIT image,
> > sign the components, then re-assemble it[0]. This would work for
> > u-boot.img and the kernel FIT images, but we would need something
> > new for re-assembling boot3.bin and tispl.bin. The first boot files
> > (boot3.bin) is also more complex that simple FIT images in that it
> > has several variations in format and content based on device family
> > and type.
> >
> > The ideal case would be we do not need to pull in the TI security tools
> > package at all and we could drop this patch. The tools would then only be
> > needed by folks wanting to sign their images using an external key
> > server.

Yes, that seems to be the bare minimum of what we should reach here.
Any tools we need should be available in 'binman tool -l' and be
fetchable / buildable with binman. It is such a pain for users if
everyone does their own thing. It is even more difficult for people
who develop U-Boot generally, since they just want to build and run.
For example, in my lab I want to be able to build U-Boot in a generic
way and have it boot on a board.

> >
> > If we could have binman learn how to generate/template x509 certs and
> > have it sign them with openssl, plus add the TI dummy[1] and degenerate[2]
> > keys to the u-boot source repo, then we would not need TI security
> > tools any more here.

OK, see the patch.

> >
> > This might be a longer term goal though, and I think we are already
> > trying to do too much all at once as is. Perhaps we could take
> > this current solution posted here with the intent to remove it in
> > the near future. Thoughts?

IMO the problem here is starting with shell scripts. They are OK for
hacking but we are trying to use a data-driven image description,
rather than having a lot of shell scripts.

It took ages to remove the SPL_FIT_GENERATOR stuff

> >
> > Andrew
> >
> > [0]
> > https://git.ti.com/cgit/security-development-tools/core-secdev-k3/tree/scripts/fit-image-secure.sh
> > [1]
> > https://git.ti.com/cgit/security-development-tools/core-secdev-k3/tree/keys/custMpk.pem
> > [2]
> > https://git.ti.com/cgit/security-development-tools/core-secdev-k3/tree/keys/ti-degenerate-key.pem
> >
>
> I think leaving the boot artifacts while going with the current solution
> would be a better option. As Andrew mentioned, the complexity mainly
> comes with the way our tiboot3.bin is packaged. It seems cleaner for now
> to go with this since this patch series is only a part in the larger
> series of packaging all the bootloader images.
>
>   I will take future action to eventually completely remove using TI
> security tools. What do you think, Simon?

I am not convinced. We still have SPL_FIT_GENERATOR after 5 years.

Can we not just do this work now? I am happy to help on the binman
side, but I have not heard back on the series I sent, so I am not sure
what is missing.

[..]
Regards,
Simon

[1] https://patchwork.ozlabs.org/project/uboot/patch/20230303000246.2640473-4-sjg@chromium.org/

More information about the U-Boot mailing list