I think it is clear Madhu has been applying due diligence here both in his own testing and notification to the project through the ML so that consumers can respond and also perform any testing they feel is necessary.
In think its appropriate for us to pause while we wait for such feedback but it would be good to have some indication on who feels there might be an issue here and wants to provide feedback.
I appreciate you are Varun and we need to analyse the risks and what mitigations need to be in place. As you may have picked up on from the various tech forums we take testing seriously and are looking to augment with different test strategies and tools however these will take time to deploy and spread their coverage through the project codebase.
Until then we will have to analyse the level of risk and apply the appropriate level of mitigations which I think Madhu has but lets see if we have some specific issues needing further mitigations to give more confidence.
Thanks
Joanna
On 19/06/2020, 23:35, "TF-A on behalf of Varun Wadekar via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote:
Hi,
Thanks for the information.
Adding libfdt to the unit testing framework is a good idea. The verification should give us more confidence on the stability side. Let’s see if platform owners would like to include more tests.
-Varun
-----Original Message-----
From: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com>
Sent: Friday, June 19, 2020 1:01 PM
To: Varun Wadekar <vwadekar(a)nvidia.com>
Cc: tf-a(a)lists.trustedfirmware.org
Subject: RE: [TF-A] Upgrading libfdt library
External email: Use caution opening links or attachments
Hi Varun
I tested the patch by running all applicable tf-a-tests suites [1] and Linux boot tests on FVP and Juno platforms. Since libfdt is platform agnostic, we are planning on adding it to the unit test framework as well(which was described in yesterday's tech forum). I need to admit that I am (over!) confident about libfdt since it is also used in U-boot and Linux projects. It seems the release tags don’t have much significance in the dtc project. Hence, I picked the latest commit at the time.
In our internal CI, we also run Coverity MISRA and other static checks to find issues in TF-A and fix them as needed. However, we don’t fix issues reported in 3rd party libraries such as libfdt. I am waiting to hear feedback from various platform owners if they have any issues with this upgrade.
[1] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests
Thanks,
Madhukar
-----Original Message-----
From: Varun Wadekar <vwadekar(a)nvidia.com>
Sent: Thursday, June 18, 2020 1:30 PM
To: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com>
Cc: tf-a(a)lists.trustedfirmware.org
Subject: RE: [TF-A] Upgrading libfdt library
Hi,
I think there are some valid concerns raised in the thread. Since this is an external project I felt we needed to set a criteria for the upgrade. One day, when we start using the unit testing framework and have 100% coverage numbers and solid positive/negative testing, we would be more confident. Until then we just have to live with what have.
@Madhukar is there any we can find out all the tests, static analysis checks, security checks that was run on the upgrade? Just trying to understand how confident we are that this does not introduce any regressions?
-Varun
-----Original Message-----
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghu K via TF-A
Sent: Thursday, June 18, 2020 9:07 AM
To: tf-a(a)lists.trustedfirmware.org
Subject: Re: [TF-A] Upgrading libfdt library
External email: Use caution opening links or attachments
One thing that might be worth considering is versioning the library like xlat_tables and xlat_tables_v2 for a few releases and deprecate the old one if/when there is broad agreement from platforms to move to the new one. Platforms can perform their independent testing like STM and can report back over time. Obviously, for those few releases if there are API changes in libfdt there will have to be support for both new and old api's which will cause temporary ugliness but this might ease concerns about testing, stability etc.
-Raghu
On 6/18/20 4:12 AM, Soby Mathew via TF-A wrote:
>> -----Original Message-----
>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of
>> Sandrine Bailleux via TF-A
>> Sent: 16 June 2020 13:09
>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Madhukar Pappireddy
>> <Madhukar.Pappireddy(a)arm.com>; Varun Wadekar <vwadekar(a)nvidia.com>
>> Cc: tf-a(a)lists.trustedfirmware.org
>> Subject: Re: [TF-A] Upgrading libfdt library
>>
>> Hi Alexei,
>>
>> On 6/16/20 1:51 PM, Alexei Fedorov wrote:
>>> Thanks for your very detailed explanation of the reason behind this
>>> solution.
>>> This brings the question on how do we monitor libfdt bug fixes, code
>>> cleanup, etc. (which Madhukar pointed out) and integrate these
>>> changes in TF-A source tree.
>> Right now, it is a manual process and not only for libfdt but for all
>> projects TF-A depends on. We keep an eye on them and aim at updating
>> them when necessary. Unfortunately, like any manual process, it is
>> error-prone and things might slip through the cracks. The TF-A
>> release tick is usually a good reminder to update all dependencies
>> but unfortunately libfdt has been left behind for some time (about 2 years)...
> As I recall, when we tried to update libfdt last time, there was significant code bloat in generated binary (feature creep?) and we abandoned the update. The policy was to stick to a stable version and only update if there are any bugfixes or new feature we would want to make use of.
>
> Generally speaking, we might have done several fixes in the imported 3rd party library by running static checks like for MISRA compliance etc and this has to be repeated when the library is updated. Also, for security audits, it is important to be sure of the "security status" of the imported library and hence we tended to not update for every release.
>
> But I agree that we do have to be on top of bug fixes and hence we need to update but not sure how we can balance this with concerns above.
>
> Regarding MbedTLS, being a security critical project, we would like to encourage platform integrators to take ownership of staying upto date rather than relying on update from TF-A repo. Hence the motivation to keep it separate.
>
> Best Regards
> Soby Mathew
>
>
>
>
>> Regards,
>> Sandrine
>> --
>> 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
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi,
I think there are some valid concerns raised in the thread. Since this is an external project I felt we needed to set a criteria for the upgrade. One day, when we start using the unit testing framework and have 100% coverage numbers and solid positive/negative testing, we would be more confident. Until then we just have to live with what have.
@Madhukar is there any we can find out all the tests, static analysis checks, security checks that was run on the upgrade? Just trying to understand how confident we are that this does not introduce any regressions?
-Varun
-----Original Message-----
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghu K via TF-A
Sent: Thursday, June 18, 2020 9:07 AM
To: tf-a(a)lists.trustedfirmware.org
Subject: Re: [TF-A] Upgrading libfdt library
External email: Use caution opening links or attachments
One thing that might be worth considering is versioning the library like xlat_tables and xlat_tables_v2 for a few releases and deprecate the old one if/when there is broad agreement from platforms to move to the new one. Platforms can perform their independent testing like STM and can report back over time. Obviously, for those few releases if there are API changes in libfdt there will have to be support for both new and old api's which will cause temporary ugliness but this might ease concerns about testing, stability etc.
-Raghu
On 6/18/20 4:12 AM, Soby Mathew via TF-A wrote:
>> -----Original Message-----
>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of
>> Sandrine Bailleux via TF-A
>> Sent: 16 June 2020 13:09
>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Madhukar Pappireddy
>> <Madhukar.Pappireddy(a)arm.com>; Varun Wadekar <vwadekar(a)nvidia.com>
>> Cc: tf-a(a)lists.trustedfirmware.org
>> Subject: Re: [TF-A] Upgrading libfdt library
>>
>> Hi Alexei,
>>
>> On 6/16/20 1:51 PM, Alexei Fedorov wrote:
>>> Thanks for your very detailed explanation of the reason behind this
>>> solution.
>>> This brings the question on how do we monitor libfdt bug fixes, code
>>> cleanup, etc. (which Madhukar pointed out) and integrate these
>>> changes in TF-A source tree.
>> Right now, it is a manual process and not only for libfdt but for all
>> projects TF-A depends on. We keep an eye on them and aim at updating
>> them when necessary. Unfortunately, like any manual process, it is
>> error-prone and things might slip through the cracks. The TF-A
>> release tick is usually a good reminder to update all dependencies
>> but unfortunately libfdt has been left behind for some time (about 2 years)...
> As I recall, when we tried to update libfdt last time, there was significant code bloat in generated binary (feature creep?) and we abandoned the update. The policy was to stick to a stable version and only update if there are any bugfixes or new feature we would want to make use of.
>
> Generally speaking, we might have done several fixes in the imported 3rd party library by running static checks like for MISRA compliance etc and this has to be repeated when the library is updated. Also, for security audits, it is important to be sure of the "security status" of the imported library and hence we tended to not update for every release.
>
> But I agree that we do have to be on top of bug fixes and hence we need to update but not sure how we can balance this with concerns above.
>
> Regarding MbedTLS, being a security critical project, we would like to encourage platform integrators to take ownership of staying upto date rather than relying on update from TF-A repo. Hence the motivation to keep it separate.
>
> Best Regards
> Soby Mathew
>
>
>
>
>> Regards,
>> Sandrine
>> --
>> 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
Hello everyone,
I would like to start a discussion around the way we want to handle
changes that affect all platforms/users. This subject came up in this
code review [1].
I'll present my views on the subject and would like to know what others
think.
First of all, what do we mean by "changes that affect all platforms"? It
would be any change that is not self-contained within a platform port.
IOW, a change in some file outside of the plat/ directory. It could be
in a driver, in a library, in the build system, in the platform
interfaces called by the generic code... the list goes on.
1. Some are just implementation changes, they leave the interfaces
unchanged. These do not break other platforms builds since the call
sites don't need to be updated. However, they potentially change the
responsibilities of the interface, in which case this might introduce
behavioral changes that all users of the interface need to be aware of
and adapt their code to.
2. Some other changes might introduce optional improvements. They
introduce a new way of doing things, perhaps a cleaner or more efficient
one. Users can safely stay with the old way of doing things without fear
of breakage but they would benefit from migrating.
This is the case of Alexei's patch [1], which introduces an intermediate
GICv2 makefile, that Arm platforms now include instead of pulling each
individual file by themselves. At this point, it is just an improvement
that introduces an indirection level in the build system. This is an
improvement in terms of maintainability because if we add a new
essential file to this driver in the future, we'll just need to add it
in this new GICv2 makefile without having to update all platforms
makefiles. However, platform makefiles can continue to pull in
individual files if they wish to.
3. Some other changes might break backwards compatibility. This is
something we should avoid as much as possible and we should always
strive to provide a migration path. But there are cases where there
might be no other way than to break things. In this case, all users have
to be migrated.
Now the question we were pondering in Gerrit is, where does the
responsibility of migrating all platforms/users lie for all these types
of changes? Is the patch author responsible to do all the work?
I think it's hard to come up with a one-size-fits-all answer. It really
depends on the nature of changes, their consequences, the amount of work
needed to do the migration, the ability for the patch author to test
these changes, to name a few.
I believe the patch author should migrate all users on a best-effort
basis. If it's manageable then they should do the work and propose a
patch to all affected users for them to review and test on their platforms.
On the other hand, if it's too much work or impractical, then I think
the best approach would be for the patch author to announce and discuss
the changes on this mailing list. In some scenarios, the changes might
be controversial and not all platform owners might agree that the patch
brings enough benefit compared to the migration effort, in which case
the changes might have to be withdrawn or re-thought. In any case, I
believe communication is key here and no one should take any unilateral
decision on their own if it affects other users.
I realize this is a vast subject and that we probably won't come up with
an answer/reach an agreement on all the aspects of the question. But I'd
be interested in hearing other contributors' view and if they've got any
experience managing these kinds of issues, perhaps in other open source
project.
Best regards,
Sandrine
[1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4538
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
One thing that might be worth considering is versioning the library like
xlat_tables and xlat_tables_v2 for a few releases and deprecate the old
one if/when there is broad agreement from platforms to move to the new
one. Platforms can perform their independent testing like STM and can
report back over time. Obviously, for those few releases if there are
API changes in libfdt there will have to be support for both new and old
api's which will cause temporary ugliness but this might ease concerns
about testing, stability etc.
-Raghu
On 6/18/20 4:12 AM, Soby Mathew via TF-A wrote:
>> -----Original Message-----
>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandrine
>> Bailleux via TF-A
>> Sent: 16 June 2020 13:09
>> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Madhukar Pappireddy
>> <Madhukar.Pappireddy(a)arm.com>; Varun Wadekar <vwadekar(a)nvidia.com>
>> Cc: tf-a(a)lists.trustedfirmware.org
>> Subject: Re: [TF-A] Upgrading libfdt library
>>
>> Hi Alexei,
>>
>> On 6/16/20 1:51 PM, Alexei Fedorov wrote:
>>> Thanks for your very detailed explanation of the reason behind this
>>> solution.
>>> This brings the question on how do we monitor libfdt bug fixes, code
>>> cleanup, etc. (which Madhukar pointed out) and integrate these changes
>>> in TF-A source tree.
>> Right now, it is a manual process and not only for libfdt but for all projects TF-A
>> depends on. We keep an eye on them and aim at updating them when
>> necessary. Unfortunately, like any manual process, it is error-prone and things
>> might slip through the cracks. The TF-A release tick is usually a good reminder
>> to update all dependencies but unfortunately libfdt has been left behind for
>> some time (about 2 years)...
> As I recall, when we tried to update libfdt last time, there was significant code bloat in generated binary (feature creep?) and we abandoned the update. The policy was to stick to a stable version and only update if there are any bugfixes or new feature we would want to make use of.
>
> Generally speaking, we might have done several fixes in the imported 3rd party library by running static checks like for MISRA compliance etc and this has to be repeated when the library is updated. Also, for security audits, it is important to be sure of the "security status" of the imported library and hence we tended to not update for every release.
>
> But I agree that we do have to be on top of bug fixes and hence we need to update but not sure how we can balance this with concerns above.
>
> Regarding MbedTLS, being a security critical project, we would like to encourage platform integrators to take ownership of staying upto date rather than relying on update from TF-A repo. Hence the motivation to keep it separate.
>
> Best Regards
> Soby Mathew
>
>
>
>
>> Regards,
>> Sandrine
>> --
>> TF-A mailing list
>> TF-A(a)lists.trustedfirmware.org
>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandrine
> Bailleux via TF-A
> Sent: 16 June 2020 13:09
> To: Alexei Fedorov <Alexei.Fedorov(a)arm.com>; Madhukar Pappireddy
> <Madhukar.Pappireddy(a)arm.com>; Varun Wadekar <vwadekar(a)nvidia.com>
> Cc: tf-a(a)lists.trustedfirmware.org
> Subject: Re: [TF-A] Upgrading libfdt library
>
> Hi Alexei,
>
> On 6/16/20 1:51 PM, Alexei Fedorov wrote:
> > Thanks for your very detailed explanation of the reason behind this
> > solution.
> > This brings the question on how do we monitor libfdt bug fixes, code
> > cleanup, etc. (which Madhukar pointed out) and integrate these changes
> > in TF-A source tree.
>
> Right now, it is a manual process and not only for libfdt but for all projects TF-A
> depends on. We keep an eye on them and aim at updating them when
> necessary. Unfortunately, like any manual process, it is error-prone and things
> might slip through the cracks. The TF-A release tick is usually a good reminder
> to update all dependencies but unfortunately libfdt has been left behind for
> some time (about 2 years)...
As I recall, when we tried to update libfdt last time, there was significant code bloat in generated binary (feature creep?) and we abandoned the update. The policy was to stick to a stable version and only update if there are any bugfixes or new feature we would want to make use of.
Generally speaking, we might have done several fixes in the imported 3rd party library by running static checks like for MISRA compliance etc and this has to be repeated when the library is updated. Also, for security audits, it is important to be sure of the "security status" of the imported library and hence we tended to not update for every release.
But I agree that we do have to be on top of bug fixes and hence we need to update but not sure how we can balance this with concerns above.
Regarding MbedTLS, being a security critical project, we would like to encourage platform integrators to take ownership of staying upto date rather than relying on update from TF-A repo. Hence the motivation to keep it separate.
Best Regards
Soby Mathew
>
> Regards,
> Sandrine
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi,
I've tested the libfdt update on STM32MP1.
I can see a boot time increase by ~6%, thanks to U-Boot 'bootstage
report' command. But I don't think this should block the lib upgrade.
I've some comments about the patch, I'll send that on gerrit.
Regards,
Yann
On 6/17/20 1:03 AM, Madhukar Pappireddy via TF-A wrote:
> Hi Varun,
>
> I have pushed the draft patch here [1] to upgrade the libfdt source
> files. I have tested this patch by running all tests that we usually run
> before merging a patch to TF-A repo. I am looking forward to receiving
> feedback from platform owners.
>
> However, I am not convinced why this effort needs an exhaustive
> evaluation with various criteria as you mentioned below. I am upgrading
> source files and I am not introducing a new project to TF-A. Let me know
> your thoughts.
>
> [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4596
>
> Thanks,
>
> Madhukar
>
> *From:* Varun Wadekar <vwadekar(a)nvidia.com>
> *Sent:* Monday, June 15, 2020 2:12 PM
> *To:* Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com>
> *Cc:* tf-a(a)lists.trustedfirmware.org
> *Subject:* RE: Upgrading libfdt library
>
> Thanks, Madhukar.
>
> I think this needs a broader discussion where we form a list evaluation
> criteria of features, API, metrics, KPIs etc by pooling them from the
> platform owners.
>
> If we don’t receive any inputs, then it makes sense to execute the
> current tests and make sure that they work as expected.
>
> Thoughts?
>
> -Varun
>
> *From:* Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com
> <mailto:Madhukar.Pappireddy@arm.com>>
> *Sent:* Monday, June 15, 2020 8:30 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: Upgrading libfdt library
>
> *External email: Use caution opening links or attachments*
>
> Hi Varun,
>
> Please find my replies inline.
>
> Thanks,
>
> Madhu
>
> *From:* Varun Wadekar <vwadekar(a)nvidia.com <mailto:vwadekar@nvidia.com>>
> *Sent:* Friday, June 12, 2020 7:04 PM
> *To:* Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com
> <mailto:Madhukar.Pappireddy@arm.com>>
> *Cc:* tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>
> *Subject:* RE: Upgrading libfdt library
>
> Hi Madhukar,
>
> Before we merge this change, can you please explain how we arrived at
> this specific version? Are we tracking the stable version of the library?
>
> >> I was told by Andre that the releases(tags) by themselves don’t mean
> much in the libfdt project and it is better to upgrade directly to the
> recent commit(the latest HEAD was 85e5d83 when I started this
> investigation).
>
> What would be the testing criteria before merging the library? Does tftf
> provide any tests that can act as a smoking gun?
>
> >> Given that we rely more on libfdt APIs now, I plan to run all the
> existing tests in our CI (includes tftf and Linux boot tests) to verify
> if the libfdt library has any issues when integrating with TF-A. I
> believe these tests are thorough enough.
>
> Does it make sense to ask platform owners to test the specific version
> you plan to merge? This way we would have more confidence in the library.
>
> >> Yes, I wanted to take the feedback from platform owners and hence I
> sent this email before actually pushing the patch to tf.org for review.
> There was a performance concern in the past when upgrading libfdt source
> files [1].
>
> [1] https://github.com/ARM-software/tf-issues/issues/643
>
> -Varun
>
> *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org
> <mailto:tf-a-bounces@lists.trustedfirmware.org>> *On Behalf Of *Madhukar
> Pappireddy via TF-A
> *Sent:* Friday, June 12, 2020 4:48 PM
> *To:* tf-a(a)lists.trustedfirmware.org <mailto:tf-a@lists.trustedfirmware.org>
> *Subject:* [TF-A] Upgrading libfdt library
>
> *External email: Use caution opening links or attachments*
>
> Hello,
>
> I am planning to upgrade libfdt library source files in TF-A. They
> haven’t been updated for a while. As the project moves towards improving
> the fconf framework and adding more properties in device tree source
> files, we rely more on libfdt APIs. I have done some preliminary
> investigation to check if there is any performance penalty in upgrading
> the libfdt source files integrated into TF-A from the current
> version(which corresponds to commit aadd0b6 in the dtc repo [1]) to
> master commit (85e5d83). I have run some basics tests on both x86 and
> aarch64 machines and I have not seen any performance degradation. I plan
> to push a patch shortly to integrate the latest version of libfdt files
> in TF-A.
>
> Please let me know if you are aware of any performance issues or have
> other concerns.
>
> [1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git
>
> Thanks,
>
> Madhu
>
Hi Madhukar,
Before we merge this change, can you please explain how we arrived at this specific version? Are we tracking the stable version of the library?
What would be the testing criteria before merging the library? Does tftf provide any tests that can act as a smoking gun?
Does it make sense to ask platform owners to test the specific version you plan to merge? This way we would have more confidence in the library.
-Varun
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Madhukar Pappireddy via TF-A
Sent: Friday, June 12, 2020 4:48 PM
To: tf-a(a)lists.trustedfirmware.org
Subject: [TF-A] Upgrading libfdt library
External email: Use caution opening links or attachments
Hello,
I am planning to upgrade libfdt library source files in TF-A. They haven't been updated for a while. As the project moves towards improving the fconf framework and adding more properties in device tree source files, we rely more on libfdt APIs. I have done some preliminary investigation to check if there is any performance penalty in upgrading the libfdt source files integrated into TF-A from the current version(which corresponds to commit aadd0b6 in the dtc repo [1]) to master commit (85e5d83). I have run some basics tests on both x86 and aarch64 machines and I have not seen any performance degradation. I plan to push a patch shortly to integrate the latest version of libfdt files in TF-A.
Please let me know if you are aware of any performance issues or have other concerns.
[1] https://git.kernel.org/pub/scm/utils/dtc/dtc.git
Thanks,
Madhu
Hi Alexei,
On 6/15/20 2:18 PM, Alexei Fedorov via TF-A wrote:
> I'm wondering why we need to integrate libfdt sources in TF-A? Why
> cannot we use the same option as for MbedTls when the build system gets
> the path to the preloaded source tree?
As far as I know, the question is the other way around: why is mbed TLS
not integrated in the TF-A source tree? If you look at the other
external libraries used by TF-A (not just libfdt, but also compiler-rt
library, zlib, ...), they all are integrated.
As far as I am aware, there are several reasons for keeping these
projects in the TF-A tree:
1) It is more developer-friendly. Whenever you clone the TF-A repo, you
get all required dependencies at the same time, no need to pull them
yourself.
2) It allows us to keep local modifications on top of mainline. Such
modifications are sometimes necessary or make our life easier to
integrate/interface the project with the rest of the TF-A code base.
3) We don't depend on the library project infrastructure. For example if
their git server is down, this would not affect us, as we've got our own
copy hosted on tf.org. Not sure this third reason was actually
considered at the time the decision was made but I see this as a tiny bonus.
Now 1) could be achieved some other way, for example we could add the
dependent projects as git submodules and have a setup script that pulls
them in. We did not go for this option at the time and I don't recall
exactly why. It might just be because of the infrastructure/setup
required to work with git submodules.
So having these projects integrated in the TF-A source tree is the
common practice in our project. As far as I am aware, the reason why we
treat mbed TLS differently is because it is very security sensitive,
thus it's important that people keep up to date with the latest version
to get all latest vulnerability fixes. If we had imported it in the TF-A
project, this would have put the onus on us to monitor mbed TLS for
security fixes and push updates as soon as they become available. This
was deemed impractical and too much responsibility for us at the time.
Regards,
Sandrine
Hello all,
I am glad to announce that Raghu Krishnamurthy has been appointed
maintainer for the TF-A project. The maintainers list has been updated
accordingly in the following patch:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/4582
Best regards,
Sandrine
