[PATCH 0/2] binman: Add support for ATF Firmware Image Package (FIP)

Wed Dec 1 17:51:08 CET 2021

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.

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.

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/

Regards,
Simon