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

[Simon Glass]

Hi François,

On Thu, 25 Nov 2021 at 10:01, François Ozog <francois.ozog at linaro.org> wrote:
>
> Hi Simon,
>
> On Thu, 25 Nov 2021 at 17:49, Simon Glass <sjg at chromium.org> wrote:
>>
>> Hi François,
>>
>> On Thu, 25 Nov 2021 at 08:11, François Ozog <francois.ozog at linaro.org> wrote:
>> >
>> > Hi Simon,
>> >
>> >
>> >
>> >
>> > On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas <ilias.apalodimas at linaro.org> wrote:
>> >>
>> >> +cc Sandrine
>> >>
>> >> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas
>> >> <ilias.apalodimas at linaro.org> wrote:
>> >> >
>> >> > Hi Simon,
>> >> >
>> >> >
>> >> > On Wed, 24 Nov 2021 at 06:09, Simon Glass <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?

In Chrome OS we package up the material that needs to be signed and
send it to a signing server, then get back a key.

You can use 'binman extract' to get the signing data, although perhaps
we could add a special option for it.

You can use 'binman replace' to add the signature in when you get it
back. Again we could create a special path for this if needed.

Regards,
Simon