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

[Sandrine Bailleux]

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.

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?

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?

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.

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.

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.