[PATCH 0/2] binman: Add support for ATF Firmware Image Package (FIP)
François Ozog
francois.ozog at linaro.org
Sat Dec 4 13:35:08 CET 2021
Hi Simon and Sandrine
Le jeu. 2 déc. 2021 à 08:10, Sandrine Bailleux <sandrine.bailleux at arm.com>
a écrit :
> Hi Simon,
>
> On 12/1/21 5:51 PM, Simon Glass wrote:
> > Hi Sandrine,
> >
> > On Wed, 1 Dec 2021 at 03:32, Sandrine Bailleux
> > <sandrine.bailleux at arm.com> wrote:
> >>
> >> Hi everyone,
> >>
> >> I am Sandrine Bailleux, from the Trusted Firmware-A project. Ilias
> >> Apalodimas CC'ed me on this thread.
> >>
> >> First of all, thanks for involving the TF-A developers in this thread
> >> and my apologies for the delay in responding.
> >
> > Thank you for your response.
> >
> >>
> >> On 11/25/21 6:01 PM, François Ozog wrote:
> >>> Hi Simon,
> >>>
> >>> On Thu, 25 Nov 2021 at 17:49, Simon Glass <sjg at chromium.org
> >>> <mailto:sjg at chromium.org>> wrote:
> >>>
> >>> Hi François,
> >>>
> >>> On Thu, 25 Nov 2021 at 08:11, François Ozog
> >>> <francois.ozog at linaro.org <mailto:francois.ozog at linaro.org>>
> wrote:
> >>> >
> >>> > Hi Simon,
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas
> >>> <ilias.apalodimas at linaro.org <mailto:ilias.apalodimas at linaro.org>>
> >>> wrote:
> >>> >>
> >>> >> +cc Sandrine
> >>> >>
> >>> >> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas
> >>> >> <ilias.apalodimas at linaro.org
> >>> <mailto:ilias.apalodimas at linaro.org>> wrote:
> >>> >> >
> >>> >> > Hi Simon,
> >>> >> >
> >>> >> >
> >>> >> > On Wed, 24 Nov 2021 at 06:09, Simon Glass <sjg at chromium.org
> >>> <mailto:sjg at chromium.org>> wrote:
> >>> >> > >
> >>> >> > >
> >>> >> > > This series adds support for the FIP format as used by ARM
> >>> Trusted
> >>> >> > > Firmware (in particular TF-A).
> >>> >> > >
> >>> >
> >>> > I will use a question you use often "what problem are you trying
> >>> to solve?". If FIP format is used it means that TF-A/BL2 is going
> to
> >>> parse it and verify the hashes/signatures according to TF-A scheme.
> >>> >
> >>> > The packager will embed in a FIP components like Secure Monitor,
> >>> Secure hypervisor, Secure partitions code and manifests.
> >>> >
> >>> > All in all, U-Boot will be representing a small percentage of the
> >>> functionality offered by secure firmware as a whole and it feels
> >>> odd to make another implementation that is more "accessory" rather
> >>> than critical for the U-Boot community. It may be a good idea but I
> >>> wish you could explain it.
> >>>
> >>> Here is a talk about Binman, its goals and how it works.
> >>>
> >>> https://www.youtube.com/watch?v=L84ujgUXBOQ
> >>>
> >>> Think of Binman as a separate tool that brings everything
> together. It
> >>> has grown out of U-Boot, largely because U-Boot is the main
> firmware
> >>> in most cases. Getting U-Boot to start up and boot successfully is
> the
> >>> goal of this packaging process. There are lots of instructions in
> the
> >>> tree and elsewhere about how to build an image comprising U-Boot
> and
> >>> various binary blobs. Binman aims to provide documentation for that
> >>> process and an image description that can be used to build an image
> >>> reliably.
> >>>
> >>> We are slowly converting these text instructions into an in-tree
> image
> >>> description.
> >>>
> >>> I believe that Binman can help bring order to the chaos that is
> >>> otherwise only going to grow, with lots of shell scripts, manual
> >>> instructions, obscure binary tools, etc. Binman brings everything
> >>> together and makes it clear what is needing/missing to build an
> image.
> >>>
> >>> >
> >>> >> > > This allows images to be created containing a FIP, which
> >>> itself contains
> >>> >> > > various binaries. With this, image creation can be handled
> >>> from an in-tree
> >>> >> > > image description instead of needing to perform a lot of
> >>> manual steps or
> >>> >> > > custom scripts to build the FIP.
> >>> >> > >
> >>> >
> >>> > That's not my experience of building a fip. Packaging even Linux
> >>> as a BL33 (instead of U-Boot) is very simple.
> >>>
> >>> But not automatic. With Binman you don't need to worry about the
> >>> packaging. It is done for you. You just need to find all the binary
> >>> blobs that are needed. This ability is quite important as
> firmware is
> >>> fragmenting and getting very complicated these days.
> >>>
> >>> Binman runs twice...once in the U-Boot tree to do a build and again
> >>> later to repackage, put in a final fdtmap, add signatures and any
> >>> final pieces needed.
> >>>
> >>> See this patch for an example of complicated build instructions
> with
> >>> Odroid-C2 (>10 binary blobs!) and how Binman can help (see the
> changes
> >>> in the .rst file):
> >>>
> >>>
> https://patchwork.ozlabs.org/project/uboot/patch/20211124040954.699821-8-sjg@chromium.org/
> >>>
> >>> That's indeed complicated! I can't comment whether this build process
> is
> >>> "canonical" as per TF-A standards so I'll let TF-A community comment.
> >>> Have you factored in the signature issues that Jan at Siemens has in the
> >>> overall process?
> >>
> >> I am a bit confused by the ask here. What input would you like from TF-A
> >> community? Are you asking for a code review or are you more interested
> >> in getting an opinion about adding support for FIP files in binman?
> >
> > The latter.
> >
> >>
> >> Regardless, I had a brief look at the patches and I have some early
> >> questions/comments.
> >>
> >> In the first patch, the commit message mentions that the tool parses the
> >> TF-A source code to get a list of supported UUIDs. However,
> >> tools/binman/fip_util.py seems to embed a hard-coded list of these
> >> UUIDs. I think I might be missing something there... Does it just mean
> >> that the said list was generated using some other script that parsed the
> >> TF-A code? Or does the tool really parse any TF-A code dynamically?
> >
> > A bit of both. The tool allows creating a new version of itself with
> > the updates parsed from the source code. For anything other than local
> > use, a patch must be submitted to do the updates.
> >
> > To run the tool::
> >
> > $ tools/binman/fip_util.py -s /path/to/arm-trusted-firmware
> > Warning: UUID 'UUID_NON_TRUSTED_WORLD_KEY_CERT' is not mentioned
> > in tbbr_config.c file
> > Existing code in 'tools/binman/fip_util.py' is up-to-date
> >
> > If it shows there is an update, it writes a new version of `fip_util.py`
> > to `fip_util.py.out`. You can change the output file using the `-i` flag.
> > If you have a problem, use `-D` to enable traceback debugging.c
> >
> > You can see that in the docs in this patch:
> >
> >
> http://patchwork.ozlabs.org/project/uboot/patch/20211123210849.2.Idf2f2a46d26cdecb56b6e9f40472f62fd062e346@changeid/
> >
> >> As you may know, we sometimes add new image types in TF-A so I am just
> >> wondering how you intend to keep in sync with these changes and how
> >> automated the process would be.
> >
> > See above.
> >
> >>
> >> I second François' concerns about having 2 different implementations of
> >> fiptool, even if you're trying to solve different (or bigger) problems
> >> here. This could be confusing for users. Also, it is likely to generate
> >> maintenance work for both TF-A and U-boot projects.
> >>
> >> I am not saying the tool should stay within the TF-A project, though.
> >> It's been in the back of our minds for some time that this tool should
> >> have a life of its own, given that it packages more than just TF-A
> >> binaries, but also the normal world bootloader, secure payload, ...
> >> Also, I must admit that a python implementation looks better than a C
> >> implementation. Rewriting the tool in a scripting language has also been
> >> a goal of ours for a long time, although we never got round to do it.
> >>
> >> Simon, you've mentioned that binman has grown out of U-Boot. How
> >> independent is it from U-Boot right now? Are there lots of assumptions
> >> about U-Boot environment in it? Or is it already a general firmware
> >> image packager in your mind? I just want to explore the idea of
> >> replacing fiptool by binman in the future. I am sure we're not there
> >> yet, neither from TF-A perspective nor U-Boot, but I'd be keen on
> >> understanding how far we are. Also, this would need discussion with the
> >> broader TF-A community.
> >
> > Binman is a general-purpose packaging tool. It has some specific
> > features for U-Boot, Chrome OS and coreboot so far. I think it could
> > cover TF-A's needs also.
> >
> > A key point is that Binman has two related purposes:
> > - building an initial image, perhaps just for development/CI purposes
> > (no signatures, some blobs missing, etc.)
> > - building a production/real image when everything is available
> >
> > This is a concept that I very much struggle to get across, the
> > difference between building things and packaging them. I believe it is
> > becoming increasingly important to make this distinction, as firmware
> > fragments.
> >
indeed. Signature workflow needs quite a lot of attention. Companies in
Global Semi-conductor Alliance are targeting also traceability are the
hardware level (able to identify the wafer origin, who cut it into chips,
PCB mounter…) and signing software/firmware will need to fit in this
process. The workgroup dealing with this is just being created.
>
> > Some people will prefer to have C tools instead of Python, but if that
> > is not a concern, then I believe Binman could be a good solution for
> > TF-A. A few nice properties are that it is easy to extend and has 100%
> > test coverage.
> >
> > I would be happy to help with what TF-A needs here.
> >
> > One last point is that Binman can provide an 'fdtmap' which is a full
> > image description. This can provide insight into every binary in the
> > image, whether it is in a FIP, FIT, CBFS or whatever. Binman happens
> > to support generating an FMAP (which is vaguely similar to FIP), which
> > could serve as a model for generating table-of-contents data in other
> > useful formats.
> >
that looks quite exciting. Have you touched base with the LunuxBoot
community which may also have some needs related to packaging?
>
> > There is a talk here that might help to explain the goals better:
> >
> > https://www.youtube.com/watch?v=L84ujgUXBOQ
> >
> > This patch shows converting lots of shell commands into a binman
> definition:
> >
> >
> https://patchwork.ozlabs.org/project/uboot/patch/20211124040954.699821-8-sjg@chromium.org/
>
> Thanks for the information, this certainly looks interesting to me in
> the context of TF-A! I'll have a closest look at the patches and
> resources you've pointed me to. I'll also talk to my team, see what they
> think and get back to you.
Simon, Sandrine, I think we had a problem with uefi signing tool being in
edk2 repo in the past. Should there be a separate project for binman
(packaging and signing) outside any firmware project ? I ask this in the
context of the GSA thing where we may have to have a tool that fits in
various industrial processes. It may become quite a rich tool and may even
need certification (just thinking out loud here). So rather than making
multiple efforts in firmware projects, we could join forces in one
dedicated project.
>
>
> Regards,
> Sandrine
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog
More information about the U-Boot
mailing list