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