Hi Varun,
Thanks for raising this topic (but please do embrace the official terminology “TF-A”…we never really promoted ATF and it's also absolutely outdated now 😉 ).
Arm has received different queries over time on supporting Trusted Firmware LTS releases, but the effort to sustain them is something that the Arm engineering team alone cannot really afford and commit to (either in the TF-A or TF-M space).
The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers, so to evaluate the possibility of a more concrete proposal to be carried on within the community Project.
I guess it will also be good to start by elaborating more concretely on the requirements that you would like to see in an hypothetical LTS versioning scheme.
Thanks
Matteo
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A
> Sent: 10 June 2020 22:47
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] ATF LTS version
>
> Hello team,
>
> To extend the discussion around version upgrades from our last call, I would like to understand if there is enough interest around generating a LTS version of the TF-A to alleviate the pain.
>
> For NVIDIA, this would be helpful as it streamlines the upgrade path for our devices in the field. The LTS version will guarantee security fixes, bug fixes, stability fixes for the longer term and we won’t have to upgrade the entire firmware to get these goodies.
>
> It would be interesting to see what OEMs and maintainers think about this? Has this been discussed at tf.org or Arm internally?
>
> -Varun
Hello Matteo,
Apologies for still using an outdated term. I have trained myself to get used to "TF-A" - looks like I am still not there.
>> The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers
That is good to hear. For the exact scope, I think we can assume the usual expectations from any LTS software stack - stability, performance, security, bug fixes along with maintenance support. We are open to discussing the cadence and any other operational commitments.
@Francois, from the description of Trusted Substrate looks like you also expect the sub-projects to provide LTS versions for the project as a whole to succeed (?)
-Varun
-----Original Message-----
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Matteo Carlini via TF-A
Sent: Thursday, June 11, 2020 4:25 AM
To: tf-a(a)lists.trustedfirmware.org
Subject: Re: [TF-A] ATF LTS version
External email: Use caution opening links or attachments
Hi Francois,
> I'd be happy to know more about what you see as TFA LTS: exact scope, number of versions, duration, operational commitments (zero-day...).
> Do you have other firmware LTS needs?
Agree. That’s precisely what I was hinting to Varun, when mentioning concrete requirements for the LTS scheme.
> Trusted Substrate is the aggregation of { TFA, OP-TEE, some TEE apps such as firmwareTPM, U-Boot }.
> Trusted Substrate effort is led by Linaro members and is going to be set up as a more open project.
First time I heard about it. Good to know, but I guess we'll need to discuss the intersection and collaboration with the Trusted Firmware project at some point.
Having a LTS versioning scheme for the Trusted Firmware hosted projects should be theoretically either in the scope of the Project itself or, if the Board agrees, appointed to some other project/entity.
> Our end goal is to enable unified, transactional, robust (anti-bricking, anti rollback) UEFI OTA on both U-Boot and EDK2.
Fair, but IMHO this has little to do with Arm Secure world software LTS releases (TF-A/Hafnium/OP-TEE/TAs, TF-M)...probably best to discuss aside, this is not in scope of what Varun is raising.
Thanks
Matteo
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi,
Would like to restart this discussion. We had a Tech Forum for this topic and talked about this in detail. The slides would be available on the TF-A wiki [1]. Please review and provide feedback or comments to help better define the scope of the problem/solution.
There was an inclination to move towards a long term support release of the firmware and the plan is to start a discussion page to get feedback from the community. I will publish more information soon.
-Varun
[1] https://www.trustedfirmware.org/meetings/tf-a-technical-forum/
From: Varun Wadekar
Sent: Friday, June 12, 2020 10:42 AM
To: François Ozog <francois.ozog(a)linaro.org>
Cc: tf-a(a)lists.trustedfirmware.org
Subject: RE: [TF-A] ATF LTS version
>> Yes. I assume relevant tf.org<http://tf.org> projects decide to branch LTSes so that we can extend the scope to selected OP-TEE TAs for the Trusted Substrate LTS and may be extend duration of support for the tf.org<http://tf.org> LTSes. (just to make sure: this is just early open thinking to understand what it would mean to build such a service on the Linaro side should there be tf.org<http://tf.org> LTSes).
Makes sense. For any platform owner, Trusted Substrate LTS would be a very compelling service.
From: François Ozog <francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org>>
Sent: Friday, June 12, 2020 5:51 AM
To: Varun Wadekar <vwadekar(a)nvidia.com<mailto:vwadekar@nvidia.com>>
Cc: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>
Subject: Re: [TF-A] ATF LTS version
External email: Use caution opening links or attachments
On Thu, 11 Jun 2020 at 23:42, Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote:
Hello Matteo,
Apologies for still using an outdated term. I have trained myself to get used to "TF-A" - looks like I am still not there.
>> The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers
That is good to hear. For the exact scope, I think we can assume the usual expectations from any LTS software stack - stability, performance, security, bug fixes along with maintenance support. We are open to discussing the cadence and any other operational commitments.
@Francois, from the description of Trusted Substrate looks like you also expect the sub-projects to provide LTS versions for the project as a whole to succeed (?)
Yes. I assume relevant tf.org<http://tf.org> projects decide to branch LTSes so that we can extend the scope to selected OP-TEE TAs for the Trusted Substrate LTS and may be extend duration of support for the tf.org<http://tf.org> LTSes. (just to make sure: this is just early open thinking to understand what it would mean to build such a service on the Linaro side should there be tf.org<http://tf.org> LTSes).
-Varun
-----Original Message-----
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Matteo Carlini via TF-A
Sent: Thursday, June 11, 2020 4:25 AM
To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>
Subject: Re: [TF-A] ATF LTS version
External email: Use caution opening links or attachments
Hi Francois,
> I'd be happy to know more about what you see as TFA LTS: exact scope, number of versions, duration, operational commitments (zero-day...).
> Do you have other firmware LTS needs?
Agree. That’s precisely what I was hinting to Varun, when mentioning concrete requirements for the LTS scheme.
> Trusted Substrate is the aggregation of { TFA, OP-TEE, some TEE apps such as firmwareTPM, U-Boot }.
> Trusted Substrate effort is led by Linaro members and is going to be set up as a more open project.
First time I heard about it. Good to know, but I guess we'll need to discuss the intersection and collaboration with the Trusted Firmware project at some point.
Having a LTS versioning scheme for the Trusted Firmware hosted projects should be theoretically either in the scope of the Project itself or, if the Board agrees, appointed to some other project/entity.
> Our end goal is to enable unified, transactional, robust (anti-bricking, anti rollback) UEFI OTA on both U-Boot and EDK2.
Fair, but IMHO this has little to do with Arm Secure world software LTS releases (TF-A/Hafnium/OP-TEE/TAs, TF-M)...probably best to discuss aside, this is not in scope of what Varun is raising.
Thanks
Matteo
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
--
[Image removed by sender.]
François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group
T: +33.67221.6485
francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog
>> Yes. I assume relevant tf.org<http://tf.org> projects decide to branch LTSes so that we can extend the scope to selected OP-TEE TAs for the Trusted Substrate LTS and may be extend duration of support for the tf.org<http://tf.org> LTSes. (just to make sure: this is just early open thinking to understand what it would mean to build such a service on the Linaro side should there be tf.org<http://tf.org> LTSes).
Makes sense. For any platform owner, Trusted Substrate LTS would be a very compelling service.
From: François Ozog <francois.ozog(a)linaro.org>
Sent: Friday, June 12, 2020 5:51 AM
To: Varun Wadekar <vwadekar(a)nvidia.com>
Cc: tf-a(a)lists.trustedfirmware.org
Subject: Re: [TF-A] ATF LTS version
External email: Use caution opening links or attachments
On Thu, 11 Jun 2020 at 23:42, Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>> wrote:
Hello Matteo,
Apologies for still using an outdated term. I have trained myself to get used to "TF-A" - looks like I am still not there.
>> The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers
That is good to hear. For the exact scope, I think we can assume the usual expectations from any LTS software stack - stability, performance, security, bug fixes along with maintenance support. We are open to discussing the cadence and any other operational commitments.
@Francois, from the description of Trusted Substrate looks like you also expect the sub-projects to provide LTS versions for the project as a whole to succeed (?)
Yes. I assume relevant tf.org<http://tf.org> projects decide to branch LTSes so that we can extend the scope to selected OP-TEE TAs for the Trusted Substrate LTS and may be extend duration of support for the tf.org<http://tf.org> LTSes. (just to make sure: this is just early open thinking to understand what it would mean to build such a service on the Linaro side should there be tf.org<http://tf.org> LTSes).
-Varun
-----Original Message-----
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org<mailto:tf-a-bounces@lists.trustedfirmware.org>> On Behalf Of Matteo Carlini via TF-A
Sent: Thursday, June 11, 2020 4:25 AM
To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>
Subject: Re: [TF-A] ATF LTS version
External email: Use caution opening links or attachments
Hi Francois,
> I'd be happy to know more about what you see as TFA LTS: exact scope, number of versions, duration, operational commitments (zero-day...).
> Do you have other firmware LTS needs?
Agree. That’s precisely what I was hinting to Varun, when mentioning concrete requirements for the LTS scheme.
> Trusted Substrate is the aggregation of { TFA, OP-TEE, some TEE apps such as firmwareTPM, U-Boot }.
> Trusted Substrate effort is led by Linaro members and is going to be set up as a more open project.
First time I heard about it. Good to know, but I guess we'll need to discuss the intersection and collaboration with the Trusted Firmware project at some point.
Having a LTS versioning scheme for the Trusted Firmware hosted projects should be theoretically either in the scope of the Project itself or, if the Board agrees, appointed to some other project/entity.
> Our end goal is to enable unified, transactional, robust (anti-bricking, anti rollback) UEFI OTA on both U-Boot and EDK2.
Fair, but IMHO this has little to do with Arm Secure world software LTS releases (TF-A/Hafnium/OP-TEE/TAs, TF-M)...probably best to discuss aside, this is not in scope of what Varun is raising.
Thanks
Matteo
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
--
[Image removed by sender.]
François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group
T: +33.67221.6485
francois.ozog(a)linaro.org<mailto:francois.ozog@linaro.org> | Skype: ffozog
Hi Varun,
I guess this suggestion came in response to last weeks Tech Forum discussion from a question about experiences people had from migrating to different TF-A tagged releases. In general we try and keep the tip of Master at tagged release quality through an extensive CI system ran on each patch. I appreciate this CI is currently a little opaque to many contributors as this is still in the process of being transitioned to the OpenCI hosted by Trustedfirmware.org servers which will be visible to all. As mentioned in the recent "Overview of the TF-A v2.3 Release" presentation on https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ the additional testing done for a 6 monthly tagged release is quite minimal and the larger work is ensuring all documentation is up to date. Additionally all new features are generally behind their own build flags but I appreciate it is some work for a tagged release to be absorbed into product offerings.
I asked at the tech forum last week what more we could do to allow releases to be integrated more easily. On the call it was requested if we could disable weak bindings to symbols so it could be more easily seen where platform decisions may need to be made and we will look into this. If there are any more adjustments to the way tagged releases are produced please let us know.
One thing that had been considered briefly was the production of a security bug only branch that was maintained only between 6 month tagged releases before being replaced by the next security bug only branch based on the next 6 month release but that has not progressed very far as a proposal as until your email here it was perceived to not be in demand. A LTS branch is a larger endeavour as it sounds like something that includes more than security fixes and I look forward to you elaborating more as Matteo requests.
Thanks
Joanna
On 11/06/2020, 12:19, "Matteo Carlini via TF-A" <tf-a(a)lists.trustedfirmware.org> wrote:
Hi Varun,
Thanks for raising this topic (but please do embrace the official terminology “TF-A”…we never really promoted ATF and it's also absolutely outdated now 😉 ).
Arm has received different queries over time on supporting Trusted Firmware LTS releases, but the effort to sustain them is something that the Arm engineering team alone cannot really afford and commit to (either in the TF-A or TF-M space).
The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers, so to evaluate the possibility of a more concrete proposal to be carried on within the community Project.
I guess it will also be good to start by elaborating more concretely on the requirements that you would like to see in an hypothetical LTS versioning scheme.
Thanks
Matteo
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A
> Sent: 10 June 2020 22:47
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] ATF LTS version
>
> Hello team,
>
> To extend the discussion around version upgrades from our last call, I would like to understand if there is enough interest around generating a LTS version of the TF-A to alleviate the pain.
>
> For NVIDIA, this would be helpful as it streamlines the upgrade path for our devices in the field. The LTS version will guarantee security fixes, bug fixes, stability fixes for the longer term and we won’t have to upgrade the entire firmware to get these goodies.
>
> It would be interesting to see what OEMs and maintainers think about this? Has this been discussed at tf.org or Arm internally?
>
> -Varun
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Varun,
There are early discussions in Linaro on what would mean setting up
"Collaborative LTS" for what we call Trusted Substrate (see below
signature).
I'd be happy to know more about what you see as TFA LTS: exact scope,
number of versions, duration, operational commitments (zero-day...).
Do you have other firmware LTS needs?
Cheers
François-Frédéric Ozog
Linaro
Trusted Substrate is the aggregation of { TFA, OP-TEE, some TEE apps such
as firmwareTPM, U-Boot }.
Trusted Substrate effort is led by Linaro members and is going to be set up
as a more open project.
Our end goal is to enable unified, transactional, robust (anti-bricking,
anti rollback) UEFI OTA on both U-Boot and EDK2.
On Wed, 10 Jun 2020 at 23:47, Varun Wadekar via TF-A <
tf-a(a)lists.trustedfirmware.org> wrote:
> Hello team,
>
>
>
> To extend the discussion around version upgrades from our last call, I
> would like to understand if there is enough interest around generating a
> LTS version of the TF-A to alleviate the pain.
>
>
>
> For NVIDIA, this would be helpful as it streamlines the upgrade path for
> our devices in the field. The LTS version will guarantee security fixes,
> bug fixes, stability fixes for the longer term and we won’t have to upgrade
> the entire firmware to get these goodies.
>
>
>
> It would be interesting to see what OEMs and maintainers think about this?
> Has this been discussed at tf.org or Arm internally?
>
>
>
> -Varun
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
Hi Francois,
> I'd be happy to know more about what you see as TFA LTS: exact scope, number of versions, duration, operational commitments (zero-day...).
> Do you have other firmware LTS needs?
Agree. That’s precisely what I was hinting to Varun, when mentioning concrete requirements for the LTS scheme.
> Trusted Substrate is the aggregation of { TFA, OP-TEE, some TEE apps such as firmwareTPM, U-Boot }.
> Trusted Substrate effort is led by Linaro members and is going to be set up as a more open project.
First time I heard about it. Good to know, but I guess we'll need to discuss the intersection and collaboration with the Trusted Firmware project at some point.
Having a LTS versioning scheme for the Trusted Firmware hosted projects should be theoretically either in the scope of the Project itself or, if the Board agrees, appointed to some other project/entity.
> Our end goal is to enable unified, transactional, robust (anti-bricking, anti rollback) UEFI OTA on both U-Boot and EDK2.
Fair, but IMHO this has little to do with Arm Secure world software LTS releases (TF-A/Hafnium/OP-TEE/TAs, TF-M)...probably best to discuss aside, this is not in scope of what Varun is raising.
Thanks
Matteo
On Thu, 11 Jun 2020 at 23:42, Varun Wadekar via TF-A <
tf-a(a)lists.trustedfirmware.org> wrote:
> Hello Matteo,
>
> Apologies for still using an outdated term. I have trained myself to get
> used to "TF-A" - looks like I am still not there.
>
> >> The idea has also been just raised to the Trusted Firmware project
> Board for initial consideration and we will be all very keen to understand
> how much interest there is from the wider TF-A community of adopters and
> external (non-Arm) maintainers
>
> That is good to hear. For the exact scope, I think we can assume the usual
> expectations from any LTS software stack - stability, performance,
> security, bug fixes along with maintenance support. We are open to
> discussing the cadence and any other operational commitments.
>
> @Francois, from the description of Trusted Substrate looks like you also
> expect the sub-projects to provide LTS versions for the project as a whole
> to succeed (?)
>
> Yes. I assume relevant tf.org projects decide to branch LTSes so that we
can extend the scope to selected OP-TEE TAs for the Trusted Substrate LTS
and may be extend duration of support for the tf.org LTSes. (just to make
sure: this is just early open thinking to understand what it would mean to
build such a service on the Linaro side should there be tf.org LTSes).
-Varun
>
>
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Matteo
> Carlini via TF-A
> Sent: Thursday, June 11, 2020 4:25 AM
> To: tf-a(a)lists.trustedfirmware.org
> Subject: Re: [TF-A] ATF LTS version
>
> External email: Use caution opening links or attachments
>
>
> Hi Francois,
>
> > I'd be happy to know more about what you see as TFA LTS: exact scope,
> number of versions, duration, operational commitments (zero-day...).
> > Do you have other firmware LTS needs?
>
> Agree. That’s precisely what I was hinting to Varun, when mentioning
> concrete requirements for the LTS scheme.
>
> > Trusted Substrate is the aggregation of { TFA, OP-TEE, some TEE apps
> such as firmwareTPM, U-Boot }.
> > Trusted Substrate effort is led by Linaro members and is going to be set
> up as a more open project.
>
> First time I heard about it. Good to know, but I guess we'll need to
> discuss the intersection and collaboration with the Trusted Firmware
> project at some point.
> Having a LTS versioning scheme for the Trusted Firmware hosted projects
> should be theoretically either in the scope of the Project itself or, if
> the Board agrees, appointed to some other project/entity.
>
> > Our end goal is to enable unified, transactional, robust (anti-bricking,
> anti rollback) UEFI OTA on both U-Boot and EDK2.
>
> Fair, but IMHO this has little to do with Arm Secure world software LTS
> releases (TF-A/Hafnium/OP-TEE/TAs, TF-M)...probably best to discuss aside,
> this is not in scope of what Varun is raising.
>
> Thanks
> Matteo
>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
>
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
Hello Joanna,
I had discussed the idea with Matteo in the past, but the discussion in the last tech forum prompted the email.
>> I appreciate this CI is currently a little opaque to many contributors as this is still in the process of being transitioned to the OpenCI hosted by Trustedfirmware.org servers which will be visible to all
I agree, it is hard to test all the use cases. The opaque nature of the CI is a bit annoying, but not a big issue.
>> the additional testing done for a 6 monthly tagged release is quite minimal and the larger work is ensuring all documentation is up to date. Additionally all new features are generally behind their own build flags but I appreciate it is some work for a tagged release to be absorbed into product offerings.
Interesting In one of our internal discussions we were exploring the possibility of using doxygen style comments and creating an API reference for a release without a lot of effort. We should try to explore this idea in the community.
>> One thing that had been considered briefly was the production of a security bug only branch
That is a good idea and can act as the base for the LTS version. But we should consider increasing the scope and include bug fixes, stability issues, performance issues, etc. I believe when the community widely adopts TFTF and starts upstreaming the test cases, we can expect more interest around a LTS release.
For platform owners (e.g. NVIDIA) it makes sense to plan our release strategy around LTS versions. Right now, our releases lack direction as we don’t know which version to use. And then there is additional pain of rebasing recent fixes/improvements on older releases.
-Varun
-----Original Message-----
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Joanna Farley via TF-A
Sent: Thursday, June 11, 2020 6:47 AM
To: Matteo Carlini <Matteo.Carlini(a)arm.com>; tf-a(a)lists.trustedfirmware.org
Subject: Re: [TF-A] ATF LTS version
External email: Use caution opening links or attachments
Hi Varun,
I guess this suggestion came in response to last weeks Tech Forum discussion from a question about experiences people had from migrating to different TF-A tagged releases. In general we try and keep the tip of Master at tagged release quality through an extensive CI system ran on each patch. I appreciate this CI is currently a little opaque to many contributors as this is still in the process of being transitioned to the OpenCI hosted by Trustedfirmware.org servers which will be visible to all. As mentioned in the recent "Overview of the TF-A v2.3 Release" presentation on https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ the additional testing done for a 6 monthly tagged release is quite minimal and the larger work is ensuring all documentation is up to date. Additionally all new features are generally behind their own build flags but I appreciate it is some work for a tagged release to be absorbed into product offerings.
I asked at the tech forum last week what more we could do to allow releases to be integrated more easily. On the call it was requested if we could disable weak bindings to symbols so it could be more easily seen where platform decisions may need to be made and we will look into this. If there are any more adjustments to the way tagged releases are produced please let us know.
One thing that had been considered briefly was the production of a security bug only branch that was maintained only between 6 month tagged releases before being replaced by the next security bug only branch based on the next 6 month release but that has not progressed very far as a proposal as until your email here it was perceived to not be in demand. A LTS branch is a larger endeavour as it sounds like something that includes more than security fixes and I look forward to you elaborating more as Matteo requests.
Thanks
Joanna
On 11/06/2020, 12:19, "Matteo Carlini via TF-A" <tf-a(a)lists.trustedfirmware.org> wrote:
Hi Varun,
Thanks for raising this topic (but please do embrace the official terminology “TF-A”…we never really promoted ATF and it's also absolutely outdated now 😉 ).
Arm has received different queries over time on supporting Trusted Firmware LTS releases, but the effort to sustain them is something that the Arm engineering team alone cannot really afford and commit to (either in the TF-A or TF-M space).
The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers, so to evaluate the possibility of a more concrete proposal to be carried on within the community Project.
I guess it will also be good to start by elaborating more concretely on the requirements that you would like to see in an hypothetical LTS versioning scheme.
Thanks
Matteo
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A
> Sent: 10 June 2020 22:47
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] ATF LTS version
>
> Hello team,
>
> To extend the discussion around version upgrades from our last call, I would like to understand if there is enough interest around generating a LTS version of the TF-A to alleviate the pain.
>
> For NVIDIA, this would be helpful as it streamlines the upgrade path for our devices in the field. The LTS version will guarantee security fixes, bug fixes, stability fixes for the longer term and we won’t have to upgrade the entire firmware to get these goodies.
>
> It would be interesting to see what OEMs and maintainers think about this? Has this been discussed at tf.org or Arm internally?
>
> -Varun
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
I should also mention the Release processes we follow and the attempt to indicated the deprecation of interfaces in advance in the effort to maintain compatibility https://trustedfirmware-a.readthedocs.io/en/latest/about/release-informatio…
On 11/06/2020, 14:47, "TF-A on behalf of Joanna Farley via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote:
Hi Varun,
I guess this suggestion came in response to last weeks Tech Forum discussion from a question about experiences people had from migrating to different TF-A tagged releases. In general we try and keep the tip of Master at tagged release quality through an extensive CI system ran on each patch. I appreciate this CI is currently a little opaque to many contributors as this is still in the process of being transitioned to the OpenCI hosted by Trustedfirmware.org servers which will be visible to all. As mentioned in the recent "Overview of the TF-A v2.3 Release" presentation on https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ the additional testing done for a 6 monthly tagged release is quite minimal and the larger work is ensuring all documentation is up to date. Additionally all new features are generally behind their own build flags but I appreciate it is some work for a tagged release to be absorbed into product offerings.
I asked at the tech forum last week what more we could do to allow releases to be integrated more easily. On the call it was requested if we could disable weak bindings to symbols so it could be more easily seen where platform decisions may need to be made and we will look into this. If there are any more adjustments to the way tagged releases are produced please let us know.
One thing that had been considered briefly was the production of a security bug only branch that was maintained only between 6 month tagged releases before being replaced by the next security bug only branch based on the next 6 month release but that has not progressed very far as a proposal as until your email here it was perceived to not be in demand. A LTS branch is a larger endeavour as it sounds like something that includes more than security fixes and I look forward to you elaborating more as Matteo requests.
Thanks
Joanna
On 11/06/2020, 12:19, "Matteo Carlini via TF-A" <tf-a(a)lists.trustedfirmware.org> wrote:
Hi Varun,
Thanks for raising this topic (but please do embrace the official terminology “TF-A”…we never really promoted ATF and it's also absolutely outdated now 😉 ).
Arm has received different queries over time on supporting Trusted Firmware LTS releases, but the effort to sustain them is something that the Arm engineering team alone cannot really afford and commit to (either in the TF-A or TF-M space).
The idea has also been just raised to the Trusted Firmware project Board for initial consideration and we will be all very keen to understand how much interest there is from the wider TF-A community of adopters and external (non-Arm) maintainers, so to evaluate the possibility of a more concrete proposal to be carried on within the community Project.
I guess it will also be good to start by elaborating more concretely on the requirements that you would like to see in an hypothetical LTS versioning scheme.
Thanks
Matteo
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Varun Wadekar via TF-A
> Sent: 10 June 2020 22:47
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] ATF LTS version
>
> Hello team,
>
> To extend the discussion around version upgrades from our last call, I would like to understand if there is enough interest around generating a LTS version of the TF-A to alleviate the pain.
>
> For NVIDIA, this would be helpful as it streamlines the upgrade path for our devices in the field. The LTS version will guarantee security fixes, bug fixes, stability fixes for the longer term and we won’t have to upgrade the entire firmware to get these goodies.
>
> It would be interesting to see what OEMs and maintainers think about this? Has this been discussed at tf.org or Arm internally?
>
> -Varun
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
