Hope you are well.

I might have missed the patch for the fiptool. Can you please post the link here?

Thanks

From: Varun Wadekar via TF-A <tf-a@lists.trustedfirmware.org>
Sent: Wednesday, August 30, 2023 10:39 PM
To: Olivier Deprez <Olivier.Deprez@arm.com>; Chris Kay <Chris.Kay@arm.com>
Cc: tf-a@lists.trustedfirmware.org
Subject: [TF-A] Re: Convert fiptool to Python script

External email: Use caution opening links or attachments

Great. I was also exploring the same idea. Will cherry-pick your patch once it is available.

From: Olivier Deprez <Olivier.Deprez@arm.com>
Sent: Wednesday, August 30, 2023 6:06 PM
To: Varun Wadekar <vwadekar@nvidia.com>; Chris Kay <Chris.Kay@arm.com>
Cc: tf-a@lists.trustedfirmware.org
Subject: Re: Convert fiptool to Python script

External email: Use caution opening links or attachments

Hi Varun,

This is a timely answer!

Actually I realized (and confirmed with other folks in the team) that OpenSSL is a weak dependency in that it's only used for computing and printing image hashes on the console.

The library is not functionally required to build a FIP image.

Eventually we could provide a build option for omitting the hash calculation and hence remove the need for OpenSSL fully.

I checked that building statically then no longer emits frightening warnings.

I can submit a change shortly for review.

An btw thanks Chris for the effort with investigating docker, I believe this is an alternative option if above is unsatisfying.

Regards,

Olivier.

From: Varun Wadekar <vwadekar@nvidia.com>
Sent: 30 August 2023 18:59
To: Chris Kay <Chris.Kay@arm.com>; 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,

I was on vacation, so couldn’t reply earlier.

Olivier, thanks for the explanation. Agree with Chris that using -static will introduce other issues.

Chris, the docker-based approach seems promising. Trying to emulate your solution.

Another path to solve this would be to remove the dependency on the gcc shipped with the OS distribution. That way we can compile the tool on the target machine. This does not solve the cross-repository usage problem, though.

-Varun

From: Chris Kay <Chris.Kay@arm.com>
Sent: Monday, August 21, 2023 5:35 PM
To: Olivier Deprez <Olivier.Deprez@arm.com>; 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 all,

RE: warnings, It doesn’t look like there’s any practical way to escape this – this is a limitation of glibc that is incurred because of how most distributions compile OpenSSL:

https://stackoverflow.com/a/57478728

If the intention is to build fiptool such that the binary can be redistributed, one way around this is to build it with a libc that doesn’t have this limitation (like Musl) or with a distribution of OpenSSL that has been compiled with static linking in mind. It’s a bit convoluted, but can be done with Docker:

cd $(mktemp -d)

cat > Dockerfile <<EOF

FROM alpine:3.18

VOLUME /tf-a

WORKDIR /tf-a

RUN apk add --update alpine-sdk openssl-libs-static openssl-dev

CMD ["make", "fiptool"]

EOF

docker buildx build . -t fiptool

docker run --user $UID -v ${PATH_TO_TF_A:?}:/tf-a fiptool

Some of the pros and cons of Python look like like they’ve already been hashed out, but it’s worth nothing that TF-A integrates a Poetry environment which handles our Python dependencies – it’d not be much work to have `make fiptool` automatically piped through that to avoid missing Python dependency issues, as we already do for the memory map tool. Of course, this still requires a dynamic OpenSSL implementation matching the version we need.

Perhaps another alternative would be Rust with the openssl crate (https://docs.rs/openssl/0.10.56/openssl), which has an option to automatically vendor and build the desired version of OpenSSL (including the latest). Rustls (https://docs.rs/rustls/latest/rustls/) might also be worth considering to avoid C dependencies entirely.

Chris

From: Olivier Deprez via TF-A <tf-a@lists.trustedfirmware.org>
Date: Monday, 21 August 2023 at 08:53
To: Varun Wadekar <vwadekar@nvidia.com>
Cc: tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
Subject: [TF-A] Re: Convert fiptool to Python script

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