Hi Varun,

fiptool is dynamically linked and relies on host installed libraries:

$ file fiptool
fiptool: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=496c79509cc2d9c001b82e75ed869a487fd0df2e, for GNU/Linux 3.2.0, not stripped

$ ldd fiptool
      linux-vdso.so.1 (0x00007ffdc9a56000)
      libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f49e9400000)
      libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f49e9000000)
      /lib64/ld-linux-x86-64.so.2 (0x00007f49e987d000)

By applying the -static flag, dependencies are statically linked to the executable:

diff --git a/tools/fiptool/Makefile b/tools/fiptool/Makefile
index 4bdebd923..5ecc7faea 100644
--- a/tools/fiptool/Makefile
+++ b/tools/fiptool/Makefile
@@ -72,7 +72,7 @@ all: --openssl ${PROJECT}
 
 ${PROJECT}: ${OBJECTS} Makefile
        @echo "  HOSTLD  $@"
-       ${Q}${HOSTCC} ${OBJECTS} -o $@ ${LDLIBS}
+       ${Q}${HOSTCC} ${OBJECTS} -o $@ ${LDLIBS} -static
        @${ECHO_BLANK_LINE}
        @echo "Built $@ successfully"
        @${ECHO_BLANK_LINE}


$ file fiptool
fiptool: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=481152e9e7db53a52955a2dd92feacc8083fa2c2, for GNU/Linux 3.2.0, not stripped

Though the following warnings are emitted (not yet clear how to solve this):
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-dso_dlfcn.o): in function `dlfcn_globallookup':
(.text+0x17): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-bio_addr.o): in function `BIO_lookup_ex':
(.text+0xd7f): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libcrypto.a(libcrypto-lib-bio_sock.o): in function `BIO_gethostbyname':
(.text+0x75): warning: Using 'gethostbyname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

Regards,
Olivier.
From: Varun Wadekar <vwadekar@nvidia.com>
Sent: 31 July 2023 13:11
To: Olivier Deprez <Olivier.Deprez@arm.com>
Cc: tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
Subject: RE: Convert fiptool to Python script
 
Hi Olivier,

Thanks for responding.

>> We believe a better approach would be to statically build the C version of fiptool, such that the dynamic openssl lib. is no longer required.

Can you please elaborate? Want to make sure I understand your proposal, before starting on the python script.

-Varun

-----Original Message-----
From: Olivier Deprez <Olivier.Deprez@arm.com>
Sent: Friday, July 28, 2023 1:18 PM
To: Varun Wadekar <vwadekar@nvidia.com>
Cc: tf-a@lists.trustedfirmware.org
Subject: Re: Convert fiptool to Python script

External email: Use caution opening links or attachments


Hi Varun,

It took a bit long to consolidate a reply after we've had a few internal debates (thanks George and Soby for helping):

> fiptool has a dependency on the host machine for OpenSSL and gcc.

We believe migrating to python has benefits such as moving away from a compiled language and its toolchain dependencies. And this has more robust support for arguments parsing (a good part of fiptool actually doing just this).
Despite those positive aspects, we believe this might not fully solve the problem mentioned above.
The code will effectively be more portable, although the interpreter and crypto lib. dependencies remain. A given host must install the right python version and package(s), similarly to the host requiring a toolchain and OpenSSL for the C version. I guess virtual environments exist for this (but another complication).

> fiptool resides under the TF-A repo

This is a long debate about productizing tools that are effectively primarily designed and used to support testing TF-A components.
It's all good partners use fiptool for products, but I'm afraid we TF-A are not enough aware of its uses in production. Your guidance is necessary.
One idea could be replicating the tool in a dedicated tree (e.g. through gitlab) such that a product can download just this tool and not the whole TF-A codebase.
Questions remain about who is maintaining this tree, how is the tool delivered (source code, or prebuilt), tagged, and the frequency at which this new tree is sync'ed with mainline TF-A.

> and is used by Hafnium and SPs. This creates a cross-repository dependency.

I see what you mean but strictly speaking Hafnium's project build system doesn't rely on fiptool.
TF-A consumes the Hafnium image + SP payloads to build the FIP image using fiptool.
I believe you mean that in order to build SP images that are booted by Hafnium, you need fiptool residing in TF-A build system.

Arguably, as you mentioned, the tool TF-A and Hafnium have in common is sptool and is effectively duplicated across repos:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/tools/sptool/sptool.py
https://git.trustedfirmware.org/hafnium/hafnium.git/tree/build/image/sptool.py

> we ship a prebuilt fiptool. But, due to OS dependency, this approach is not scalable across OS versions. E.g. One OS distribution might be using a lower OpenSSL version compared another, creating an incompatibility.

We believe a better approach would be to statically build the C version of fiptool, such that the dynamic openssl lib. is no longer required.

All that said, if desired, we'd be leaving the door open for Nvidia to implement a python version of fiptool for the aforementioned benefits. The deployment/environment requirement for running this script would have to be specified along with it.

Regards,
Olivier.




From: Varun Wadekar via TF-A <tf-a@lists.trustedfirmware.org>
Sent: 13 July 2023 18:11
To: tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
Subject: [TF-A] Convert fiptool to Python script

Hello,

We use fiptool extensively to generate the FIP blobs for NVIDIA platforms. But, we encountered the following issues during deployment.

fiptool has a dependency on the host machine for OpenSSL and gcc.
fiptool resides under the TF-A repo and is used by Hafnium and SPs. This creates a cross-repository dependency.

As a workaround, we ship a prebuilt fiptool. But, due to OS dependency, this approach is not scalable across OS versions. E.g. One OS distribution might be using a lower OpenSSL version compared another, creating an incompatibility.

I was thinking if converting fiptool to a python script might help resolve these issues. Sptool was converted into a Python script, so was wondering if anyone has tried converting fiptool to a Python script too.

-Varun