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@lists.trustedfirmware.org on behalf of tf-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@arm.com Sent: Friday, June 19, 2020 1:01 PM To: Varun Wadekar vwadekar@nvidia.com Cc: tf-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@nvidia.com Sent: Thursday, June 18, 2020 1:30 PM To: Madhukar Pappireddy Madhukar.Pappireddy@arm.com Cc: tf-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@lists.trustedfirmware.org On Behalf Of Raghu K via TF-A Sent: Thursday, June 18, 2020 9:07 AM To: tf-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@lists.trustedfirmware.org On Behalf Of >> Sandrine Bailleux via TF-A >> Sent: 16 June 2020 13:09 >> To: Alexei Fedorov Alexei.Fedorov@arm.com; Madhukar Pappireddy >> Madhukar.Pappireddy@arm.com; Varun Wadekar vwadekar@nvidia.com >> Cc: tf-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@lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

-- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a