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