[PATCH 0/2] binman: Add support for ATF Firmware Image Package (FIP)
Simon Glass
sjg at chromium.org
Sun Dec 5 21:00:09 CET 2021
Hi François,
On Sat, 4 Dec 2021 at 05:35, François Ozog <francois.ozog at linaro.org> wrote:
>
> 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?
No, my entire effort so far was a talk about 3 years ago.
>>
>>
>> > 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.
Maybe, people asked the same thing about patman years ago. But so far
only U-Boot has adopted it (and a bit of Chrome OS). Also, while
Binman supports some formats natively it does rely on external tools
for others, just to avoid duplication.
Re the tools that it uses, I'm hoping to add a feature which can tell
you how to get the ones that are missing, or get them automatically,
like buildman does.
I hope it can make packaging data-driven/testable, instead of
everything having untested scripts all over the place.
Regards,
Simon
>>
>>
>>
>> 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