Hi Sandrine, On Wed, 1 Dec 2021 at 03:32, Sandrine Bailleux <[email protected]> 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 <[email protected] > > <mailto:[email protected]>> wrote: > > > > Hi François, > > > > On Thu, 25 Nov 2021 at 08:11, François Ozog > > <[email protected] <mailto:[email protected]>> wrote: > > > > > > Hi Simon, > > > > > > > > > > > > > > > On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas > > <[email protected] <mailto:[email protected]>> > > wrote: > > >> > > >> +cc Sandrine > > >> > > >> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas > > >> <[email protected] > > <mailto:[email protected]>> wrote: > > >> > > > >> > Hi Simon, > > >> > > > >> > > > >> > On Wed, 24 Nov 2021 at 06:09, Simon Glass <[email protected] > > <mailto:[email protected]>> 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/[email protected]/ > > > > 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@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/[email protected]/ Regards, Simon
