Hello,
We use fiptool extensively to generate the FIP blobs for NVIDIA platforms. But, we encountered the following issues during deployment.
1. fiptool has a dependency on the host machine for OpenSSL and gcc. 2. 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
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/sptoo... https://git.trustedfirmware.org/hafnium/hafnium.git/tree/build/image/sptool....
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
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/sptoo... https://git.trustedfirmware.org/hafnium/hafnium.git/tree/build/image/sptool....
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
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/sptoo... https://git.trustedfirmware.org/hafnium/hafnium.git/tree/build/image/sptool....
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
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/sptoo... https://git.trustedfirmware.org/hafnium/hafnium.git/tree/build/image/sptool....
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
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.orgmailto:tf-a@lists.trustedfirmware.org> Date: Monday, 21 August 2023 at 08:53 To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.commailto:vwadekar@nvidia.com> Sent: 31 July 2023 13:11 To: Olivier Deprez <Olivier.Deprez@arm.commailto:Olivier.Deprez@arm.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.commailto:Olivier.Deprez@arm.com> Sent: Friday, July 28, 2023 1:18 PM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tf-a@lists.trustedfirmware.orgmailto: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/sptoo... https://git.trustedfirmware.org/hafnium/hafnium.git/tree/build/image/sptool....
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.orgmailto:tf-a@lists.trustedfirmware.org> Sent: 13 July 2023 18:11 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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
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.orgmailto:tf-a@lists.trustedfirmware.org> Date: Monday, 21 August 2023 at 08:53 To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.commailto:vwadekar@nvidia.com> Sent: 31 July 2023 13:11 To: Olivier Deprez <Olivier.Deprez@arm.commailto:Olivier.Deprez@arm.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.commailto:Olivier.Deprez@arm.com> Sent: Friday, July 28, 2023 1:18 PM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tf-a@lists.trustedfirmware.orgmailto: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/sptoo... https://git.trustedfirmware.org/hafnium/hafnium.git/tree/build/image/sptool....
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.orgmailto:tf-a@lists.trustedfirmware.org> Sent: 13 July 2023 18:11 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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
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.commailto:vwadekar@nvidia.com> Sent: 30 August 2023 18:59 To: Chris Kay <Chris.Kay@arm.commailto:Chris.Kay@arm.com>; Olivier Deprez <Olivier.Deprez@arm.commailto:Olivier.Deprez@arm.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.commailto:Chris.Kay@arm.com> Sent: Monday, August 21, 2023 5:35 PM To: Olivier Deprez <Olivier.Deprez@arm.commailto:Olivier.Deprez@arm.com>; Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tf-a@lists.trustedfirmware.orgmailto: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.orgmailto:tf-a@lists.trustedfirmware.org> Date: Monday, 21 August 2023 at 08:53 To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.commailto:vwadekar@nvidia.com> Sent: 31 July 2023 13:11 To: Olivier Deprez <Olivier.Deprez@arm.commailto:Olivier.Deprez@arm.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.commailto:Olivier.Deprez@arm.com> Sent: Friday, July 28, 2023 1:18 PM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tf-a@lists.trustedfirmware.orgmailto: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/sptoo... https://git.trustedfirmware.org/hafnium/hafnium.git/tree/build/image/sptool....
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.orgmailto:tf-a@lists.trustedfirmware.org> Sent: 13 July 2023 18:11 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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
Hi @Oliviermailto:Olivier.Deprez@arm.com,
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.commailto:Olivier.Deprez@arm.com> Sent: Wednesday, August 30, 2023 6:06 PM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>; Chris Kay <Chris.Kay@arm.commailto:Chris.Kay@arm.com> Cc: tf-a@lists.trustedfirmware.orgmailto: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.commailto:vwadekar@nvidia.com> Sent: 30 August 2023 18:59 To: Chris Kay <Chris.Kay@arm.commailto:Chris.Kay@arm.com>; Olivier Deprez <Olivier.Deprez@arm.commailto:Olivier.Deprez@arm.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.commailto:Chris.Kay@arm.com> Sent: Monday, August 21, 2023 5:35 PM To: Olivier Deprez <Olivier.Deprez@arm.commailto:Olivier.Deprez@arm.com>; Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tf-a@lists.trustedfirmware.orgmailto: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.orgmailto:tf-a@lists.trustedfirmware.org> Date: Monday, 21 August 2023 at 08:53 To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.commailto:vwadekar@nvidia.com> Sent: 31 July 2023 13:11 To: Olivier Deprez <Olivier.Deprez@arm.commailto:Olivier.Deprez@arm.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.commailto:Olivier.Deprez@arm.com> Sent: Friday, July 28, 2023 1:18 PM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tf-a@lists.trustedfirmware.orgmailto: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/sptoo... https://git.trustedfirmware.org/hafnium/hafnium.git/tree/build/image/sptool....
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.orgmailto:tf-a@lists.trustedfirmware.org> Sent: 13 July 2023 18:11 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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
Hi Varun,
I'm a good, I hope you are as well!
See the proposal https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/23561
Then build with: make -C tools/fiptool STATIC=1
and get: $ file tools/fiptool/fiptool tools/fiptool/fiptool: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, BuildID[sha1]=e2c995bc0b16eab9e1db5d6212db50fd60e2d190, for GNU/Linux 3.2.0, not stripped
$ ldd tools/fiptool/fiptool not a dynamic executable
I built it on an Ubuntu 22 host and copied straight to both an Ubuntu 18 and a Redhat 7.9 hosts. I could launch the tool without observing any obvious OS loader/lib. dependency issue.
Regards, Olivier.
________________________________ From: Varun Wadekar vwadekar@nvidia.com Sent: 25 September 2023 14:34 To: Varun Wadekar vwadekar@nvidia.com; Olivier Deprez Olivier.Deprez@arm.com; Chris Kay Chris.Kay@arm.com Cc: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: RE: Convert fiptool to Python script
Hi @Oliviermailto:Olivier.Deprez@arm.com,
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.commailto:Olivier.Deprez@arm.com> Sent: Wednesday, August 30, 2023 6:06 PM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>; Chris Kay <Chris.Kay@arm.commailto:Chris.Kay@arm.com> Cc: tf-a@lists.trustedfirmware.orgmailto: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.commailto:vwadekar@nvidia.com> Sent: 30 August 2023 18:59 To: Chris Kay <Chris.Kay@arm.commailto:Chris.Kay@arm.com>; Olivier Deprez <Olivier.Deprez@arm.commailto:Olivier.Deprez@arm.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.commailto:Chris.Kay@arm.com> Sent: Monday, August 21, 2023 5:35 PM To: Olivier Deprez <Olivier.Deprez@arm.commailto:Olivier.Deprez@arm.com>; Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tf-a@lists.trustedfirmware.orgmailto: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.orgmailto:tf-a@lists.trustedfirmware.org> Date: Monday, 21 August 2023 at 08:53 To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.commailto:vwadekar@nvidia.com> Sent: 31 July 2023 13:11 To: Olivier Deprez <Olivier.Deprez@arm.commailto:Olivier.Deprez@arm.com> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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.commailto:Olivier.Deprez@arm.com> Sent: Friday, July 28, 2023 1:18 PM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Cc: tf-a@lists.trustedfirmware.orgmailto: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/sptoo... https://git.trustedfirmware.org/hafnium/hafnium.git/tree/build/image/sptool....
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.orgmailto:tf-a@lists.trustedfirmware.org> Sent: 13 July 2023 18:11 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto: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
tf-a@lists.trustedfirmware.org
-
Chris Kay -
Olivier Deprez -
Varun Wadekar