Hi Simon and Sandrine Le jeu. 2 déc. 2021 à 08:10, Sandrine Bailleux <sandrine.baill...@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.baill...@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 <s...@chromium.org > >>> <mailto:s...@chromium.org>> wrote: > >>> > >>> Hi François, > >>> > >>> On Thu, 25 Nov 2021 at 08:11, François Ozog > >>> <francois.o...@linaro.org <mailto:francois.o...@linaro.org>> > wrote: > >>> > > >>> > Hi Simon, > >>> > > >>> > > >>> > > >>> > > >>> > On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas > >>> <ilias.apalodi...@linaro.org <mailto:ilias.apalodi...@linaro.org>> > >>> wrote: > >>> >> > >>> >> +cc Sandrine > >>> >> > >>> >> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas > >>> >> <ilias.apalodi...@linaro.org > >>> <mailto:ilias.apalodi...@linaro.org>> wrote: > >>> >> > > >>> >> > Hi Simon, > >>> >> > > >>> >> > > >>> >> > On Wed, 24 Nov 2021 at 06:09, Simon Glass <s...@chromium.org > >>> <mailto:s...@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-...@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@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? > > > 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-...@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. > > > 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.o...@linaro.org | Skype: ffozog