Hi,
As you may know, the build system was changed, and the tip of master depends on Openssl3. This version is quite new and is not available in many old (or not so old) but still supported operating systems. (Ubuntu 18.04 is an example.)
I made a quick and dirty fix to allow building Opessl3 right from TF-A if the source is pre-fetched. You can find this change here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16800 For our downstream project this is a perfect solution as the same component introducing the new dependency carries the solution. Thus, my build environment is not becoming TF-A version specific.
From TF-A point of view the situation is not so simple. The above patch extends TF-A with "build environment provisioning" responsibility. Before this patch TF-A assumed, all "common" dependencies are available in the build environment, and this patch changes that. Yes, some strongly TF-A specific components were owned and built by TF-A, but openssl is different.
Thus, my modification is a "game changer" in some ways. A few things to consider:
* Openssl becomes a special kind of TPIP which the project will need to manage (e.g. look for security risks, version updates, compatibility to different OSs and OS versions, etc...). * This is a system wide component. There is a risk of breaking something the build uses. Hidden things like a python module depending on openssl and now picking up an incompatible version. * This change might be considered as layer bleeding since it "melds" responsibilities of the TF-A project and the "owner of the build environment". IMHO this might be a significant difference from supply-chain security perspectives.
There are alternatives which might be considered better:
* making the build system and host side tooling (e.g. cert_tool) backwards compatible with openssl2 * hosting pre-built static binaries somewhere, which would simplify build environment updates
As I mentioned above, this is a "good enough" fix for my use-case, but not sure if this is the right approach from TF-A perspectives.
I am happy to tidy up this patch and push it trough the review, but the efforts needed to implement "other options" are beyond my capacity.
I am looking for feedback both from TF-A maintainers and from "build environment owners". Thanks!
/George
Ps.: Apologies for not doing "my homework". I know there is a ticket somewhere in Phabricator and I did not invest the needed time to find it.
On 9/22/22 08:46, Gyorgy Szing via TF-A wrote:
Hi,
As you may know, the build system was changed, and the tip of master depends on Openssl3. This version is quite new and is not available in many old (or not so old) but still supported operating systems. (Ubuntu 18.04 is an example.)
I made a quick and dirty fix to allow building Opessl3 right from TF-A if the source is pre-fetched. You can find this change here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16800 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16800 For our downstream project this is a perfect solution as the same component introducing the new dependency carries the solution. Thus, my build environment is not becoming TF-A version specific.
From TF-A point of view the situation is not so simple. The above patch extends TF-A with "build environment provisioning" responsibility. Before this patch TF-A assumed, all "common" dependencies are available in the build environment, and this patch changes that. Yes, some strongly TF-A specific components were owned and built by TF-A, but openssl is different.
Thus, my modification is a “game changer” in some ways. A few things to consider:
- Openssl becomes a special kind of TPIP which the project will need to manage (e.g. look for security risks, version updates, compatibility to different OSs and OS versions, etc...).
- This is a system wide component. There is a risk of breaking something the build uses. Hidden things like a python module depending on openssl and now picking up an incompatible version.
- This change might be considered as layer bleeding since it “melds” responsibilities of the TF-A project and the “owner of the build environment”. IMHO this might be a significant difference from supply-chain security perspectives.
There are alternatives which might be considered better:
- making the build system and host side tooling (e.g. cert_tool) backwards compatible with openssl2
- hosting pre-built static binaries somewhere, which would simplify build environment updates
As I mentioned above, this is a "good enough" fix for my use-case, but not sure if this is the right approach from TF-A perspectives.
I am happy to tidy up this patch and push it trough the review, but the efforts needed to implement “other options” are beyond my capacity.
I am looking for feedback both from TF-A maintainers and from “build environment owners”. Thanks!
/George
Ps.: Apologies for not doing “my homework”. I know there is a ticket somewhere in Phabricator and I did not invest the needed time to find it.
Hi György,
Thanks for the detailed explanation.
For STM32MP1, we can build TF-A directly from sources, but we also provide yocto or an SDK. In those 2 environments, openssl is alredy built, and is not in /usr. We then maintain a downstream patch to avoid the kind of issues you can have: https://github.com/STMicroelectronics/arm-trusted-firmware/commit/0415e27ad1...
But it might not be upstreamable as-is, and maybe I should rework it and test it when rebasing on v2.8 upcoming tag.
So your patch might break what we have, that's why I was asking if it was possible to have this 'build openssl' option under a dedicated flag.
Best regards, Yann
From: Yann GAUTIER - foss via TF-A tf-a@lists.trustedfirmware.org Sent: 23 September 2022 11:16 To: tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: Adding Openssl3 build capability to TF-A
On 9/22/22 08:46, Gyorgy Szing via TF-A wrote:
Hi,
As you may know, the build system was changed, and the tip of master depends on Openssl3. This version is quite new and is not available in many old (or not so old) but still supported operating systems. (Ubuntu 18.04 is an example.)
I made a quick and dirty fix to allow building Opessl3 right from TF-A if the source is pre-fetched. You can find this change here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16800 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/16800 For our downstream project this is a perfect solution as the same component introducing the new dependency carries the solution. Thus, my build environment is not becoming TF-A version specific.
From TF-A point of view the situation is not so simple. The above patch extends TF-A with "build environment provisioning" responsibility. Before this patch TF-A assumed, all "common" dependencies are available in the build environment, and this patch changes that. Yes, some strongly TF-A specific components were owned and built by TF-A, but openssl is different.
Thus, my modification is a "game changer" in some ways. A few things to consider:
- Openssl becomes a special kind of TPIP which the project will need to manage (e.g. look for security risks, version updates, compatibility to different OSs and OS versions, etc...).
- This is a system wide component. There is a risk of breaking something the build uses. Hidden things like a python module depending on openssl and now picking up an incompatible version.
- This change might be considered as layer bleeding since it "melds" responsibilities of the TF-A project and the "owner of the build environment". IMHO this might be a significant difference from supply-chain security perspectives.
There are alternatives which might be considered better:
- making the build system and host side tooling (e.g. cert_tool) backwards compatible with openssl2
- hosting pre-built static binaries somewhere, which would simplify build environment updates
As I mentioned above, this is a "good enough" fix for my use-case, but not sure if this is the right approach from TF-A perspectives.
I am happy to tidy up this patch and push it trough the review, but the efforts needed to implement "other options" are beyond my capacity.
I am looking for feedback both from TF-A maintainers and from "build environment owners". Thanks!
/George
Ps.: Apologies for not doing "my homework". I know there is a ticket somewhere in Phabricator and I did not invest the needed time to find it.
Hi György,
Thanks for the detailed explanation.
For STM32MP1, we can build TF-A directly from sources, but we also provide yocto or an SDK. In those 2 environments, openssl is alredy built, and is not in /usr. We then maintain a downstream patch to avoid the kind of issues you can have: https://github.com/STMicroelectronics/arm-trusted-firmware/commit/0415e27ad1...
But it might not be upstreamable as-is, and maybe I should rework it and test it when rebasing on v2.8 upcoming tag.
So your patch might break what we have, that's why I was asking if it was possible to have this 'build openssl' option under a dedicated flag.
Best regards, Yann
Hi, thanks for the background info. The fact there is already an openssl3 workaround in a downstream project might be an indicator for the need of an upstream solution. I imagine a process like this: - First, we need to see who is affected and what solutions do exist (we already know about two workarounds). - Then we need to agree on the proper way of fixing the issue. - Then after maintainers give green light, someone can look at implementing the changes. If you (or your team) could donate bandwidth for the design and/or implementation tasks that would be great.
I am going to comment on https://developer.trustedfirmware.org/T993 to distill information gathered till now.
/George
tf-a@lists.trustedfirmware.org
-
Gyorgy Szing -
Yann GAUTIER - foss