- TF-A - lists.trustedfirmware.org

Re: [TF-A] fconf: Validating config data

by Madhukar Pappireddy

Hi Raghu, We had a discussion internally about handling the mandatory and optional properties in fconf and we believe we can use the following approach. Please let us know if it is acceptable to you. As agreed over the mailing list, we treat the scenarios of a missing/incorrect mandatory property or a structurally bad dtb as an integration error and must lead to panic in runtime. It is the responsibility of the developer providing the populate callback to detect and return an error code in such scenarios. It will be treated as an unrecoverable error and further escalated to panic() by the fconf framework itself. An incorrect or missing optional property in a dtb should lead to a warning message and the boot loader should continue after assigning a default value to the specific property. Further, every property accessed by a populate callback should be clearly defined as either mandatory or optional in a fconf based binding document such as the one shown here [1]. This must be enforced in spirit as part of the code review process. We believe the callbacks can be categorized into two: Generic vs platform-specific. Generic callbacks are the ones that are required to support a standard component supported by platforms running TF-A such as TBBR, SDEI, IO Policy, GICv3, etc. Platform-specific callbacks are provided by platform developers to work with non-standard components such as a Proprietary Hardware IP. The binding document for generic populate callbacks should be provided by the TF-A project. The generic binding will become a contract for the platforms to implement the support for integrating standard components and hence, will be platform agnostic. Correspondingly, it is the responsibility of the platform developer to provide the binding for platform-specific populate callbacks. Any thoughts? [1] https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/fconf_p… Thanks, Madhukar -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Manish Badarkhe via TF-A Sent: Wednesday, May 20, 2020 6:00 AM To: Raghu K <raghu.ncstate(a)icloud.com>; Sandrine Bailleux <Sandrine.Bailleux(a)arm.com>; tf-a(a)lists.trustedfirmware.org; Louis Mayencourt <Louis.Mayencourt(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-A] fconf: Validating config data Hi Raghu We have plan to work on this and come up with some design which handles mandatory/critical properties. On 13/05/2020, 22:18, "TF-A on behalf of Raghu K via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi All, Since the 2.3 release is done, can we revisit this topic? I think we left this with finalizing on how to handle bad/incorrect DTB's. Sandrine's latest proposal below: "A bad DTB seems more like an integration error than a programming error to me, and thus should be handled with runtime checks according to the current guidelines. Incorrect values for mandatory properties should probably be treated as unrecoverable errors (causing a panic) and incorrect/missing optional properties as recoverable errors (issuing a warning message)." I agree with this proposal and think we should follow this. This addresses my original concern of handling errors consistently and being safe by verifying mandatory/critical properties at run-time. Thoughts ? Thanks Raghu On 4/13/20 10:27 AM, Raghu Krishnamurthy wrote: > Thanks Sandrine. Revisiting after v2.3 is sounds fine. > > -Raghu > > On 4/10/20 2:25 AM, Sandrine Bailleux wrote: >> Hi Raghu, >> >> On 4/8/20 12:50 AM, Raghu Krishnamurthy wrote: >>> Thanks Sandrine, Louis, >>> >>> Agree with both of you. I'm fine with using asserts or panics, as >>> long as we uniformly use it. The change i sent out(review 3845) was >>> because i noticed inconsistency in handling errors. If we do use >>> asserts, all code that checks for mandatory properties, should be >>> changed to assert as opposed to return error code. For optional >>> properties, we can continue to return an error code or print >>> warnings etc. >> >> Yes, I too think consistency is key here. As you said, we need to >> settle on the expected behaviour and enforce it uniformly across the >> fconf code. Let's revisit this code after the v2.3 release. >> >>> I would like to point out that using asserts here is different from >>> what is documented in the coding guidelines. The guidelines >>> explicitly spells out using asserts for "programming errors". >>> Now, is having a bad DTB considered a programming error? ;) The DTB >>> is platform data as opposed to code. The guidelines might need to be >>> updated based on the conclusion here. >> >> Now that you point it out, and after taking a closer look at [1], I >> think I was wrong. A bad DTB seems more like an integration error >> than a programming error to me, and thus should be handled with >> runtime checks according to the current guidelines. Incorrect values >> for mandatory properties should probably be treated as unrecoverable >> errors (causing a panic) and incorrect/missing optional properties as >> recoverable errors (issuing a warning message). >> >> [1] >> https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guideline… >> >> >>> Also note the couple of scenarios i mentioned in an earlier email. >>> Platforms like RPI4 don't generally enable TBBR and the DTB image >>> could get corrupt or be modified on purpose. On a release build, >>> this could cause silent corruption. Panic() would avoid this. >>> >>> In any case, it would be good to settle on the expected behavior for >>> each of these abnormal cases. I don't have a strong preference for >>> asserts or panics here, since each has its pros and cons as both of >>> you called out. >>> >>> Thanks >>> Raghu > -- 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

5 years

2
1
0 0

TF-A Tech Forum Agenda @ Thr 18th June 2020 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 18th June 2020 16:00 – 17:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. Note the new time that is an hour earlier then previous sessions. Agenda: * TF-A Unit Level Testing - Presented by Lauren Wehrmeister * General explanation of the new approach for Unit Testing in TF-A. * Optional TF-A Mailing List Topic Discussions If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Thanks Joanna

5 years

1
0
0 0

Re: [TF-A] Upgrading libfdt library

by Madhukar Pappireddy

Hi Alexei, To be clear, my current effort is to upgrade the libfdt source files in TF-A. I am not sure why the libfdt source was not integrated into TF-A as a preloaded source tree similar to MbedTLS. Perhaps, any TF-A veteran can help answer this question? Since there is an ongoing effort in the TF-A project to move to CMake build framework, I did not plan to integrate libfdt Makefile into TF-A. Hi Yann, Between commits aadd0b6 (the current version in TF-A for libfdt files) and 85e5d83, I have noticed bug fixes, code cleanups. I am not familiar with the dtc project. I can push a WIP patch with libfdt source files picked from commit 85e5d83. Please let me know if you see any issues with ST platforms. Thanks, Madhukar -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Yann GAUTIER via TF-A Sent: Monday, June 15, 2020 10:26 AM To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Upgrading libfdt library Hi Madhukar, We had seen some issue on STM32MP1 with the previous libfdt rebase, that led to the ticket [1]. And then a partial revert [2]. I'll then try this new version to check if boot time doesn't increase too much. Do you expect other changes than the one changing __ASSEMBLY__ to __ASSEMBLER__? And maybe some updates in libfdt.mk file? If you push this new version to gerrit, it will be easier to fetch and test, as a WIP if it is better for you? Regards, Yann [1] https://github.com/ARM-software/tf-issues/issues/643 [2] https://github.com/ARM-software/arm-trusted-firmware/commit/00f588bf2cc5298… On 6/15/20 2:18 PM, Alexei Fedorov via TF-A wrote: > Hi Madhukar, > > 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? > > Regards. > > Alexei > > ---------------------------------------------------------------------- > -- > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of > Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> > *Sent:* 13 June 2020 01:04 > *To:* Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> > *Cc:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > *Subject:* Re: [TF-A] 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? > > 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 > > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

5 years

1
0
0 0

Re: [TF-A] Upgrading libfdt library

by Yann GAUTIER

Hi Madhukar, We had seen some issue on STM32MP1 with the previous libfdt rebase, that led to the ticket [1]. And then a partial revert [2]. I'll then try this new version to check if boot time doesn't increase too much. Do you expect other changes than the one changing __ASSEMBLY__ to __ASSEMBLER__? And maybe some updates in libfdt.mk file? If you push this new version to gerrit, it will be easier to fetch and test, as a WIP if it is better for you? Regards, Yann [1] https://github.com/ARM-software/tf-issues/issues/643 [2] https://github.com/ARM-software/arm-trusted-firmware/commit/00f588bf2cc5298… On 6/15/20 2:18 PM, Alexei Fedorov via TF-A wrote: > Hi Madhukar, > > 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? > > Regards. > > Alexei > > ------------------------------------------------------------------------ > *From:* TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun > Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> > *Sent:* 13 June 2020 01:04 > *To:* Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> > *Cc:* tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> > *Subject:* Re: [TF-A] 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? > > 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 > >

5 years

1
0
0 0

Re: [TF-A] Upgrading libfdt library

by Alexei Fedorov

Hi Madhukar, 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? Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 13 June 2020 01:04 To: Madhukar Pappireddy <Madhukar.Pappireddy(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] 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? 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

5 years

1
0
0 0

Re: [TF-A] Question on confine_index_array.h import in tf-a

by Sandrine Bailleux

Hello Etienne, On 6/10/20 1:19 PM, Etienne Carriere via TF-A wrote: > Dear all, > > As part of a patchset series review (topic scmi-msg), change [1] > imports confine_array_index.h header file from OP-TEE OS repository. > The file originates from the open source Fuschia project, see link in > commit message of [1]. > > As being imported for external packages, the header file inherits > Fushca and OP-TEE notices. > The helper function can protect some data structure from side channel > attacks leveraging index indirect access overflows during speculative > execution. > It is not Arm copyright. It is BSD-3-Clause license. > I'll add an entry in the docs/license.rst for the file. > > Where to locate the file? > It is ok to add such a file in include/common? > Does it deserve a specific lib path, like > include/lib/speculconfie_array_index.h? > Maybe add as include/lib/cpus/confine_array_index.h as it is CPU > speculative matters? Before we discuss the location of this header file, have we considered using the compiler support for speculative execution mitigations instead? I am referring to the __builtin_speculation_safe_value() macro, which I believe achieves the same goal as the code you propose to introduce here, i.e. protecting against Spectre v1 bounds-check bypass attacks. TF-A already uses this compiler builtin today and provides a wrapper macro around it, see SPECULATION_SAFE_VALUE() in include/lib/utils_def.f (although I would argue this is not the best location one could think of...). For reference, this was introduced by commit [1]. According to Arm's whitepaper [2], the support for this compiler builtin was added in GCC 9 and LLVM/Clang was to follow shortly. If these versions are too recent for you, then I believe the official location to get equivalent code is [3]. As stated there: The header file provided here allows a migration path to using the builtin function for users who are unable to immediately upgrade to a compiler which supports the builtin. So I would prefer we get the code from there rather than from the OP-TEE project, which got it from the Fuschia project ;) This is licensed under the Boost Software License 1.0, which we've never used in TF-A so I would need to check with our legal department whether this is OK, but I don't expect any issues there as this is described as a permissive license only requiring preservation of copyright and license notices. This is assuming that both header files (the one from OP-TEE and the one from the Arm software Github repo) are equivalent... Is this the case? Is the code provided in OP-TEE perhaps more optimized? Regards, Sandrine [1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=9edd… [2] https://developer.arm.com/support/arm-security-updates/speculative-processo… [3] https://github.com/ARM-software/speculation-barrier

5 years

2
1
0 0

Invitation: TF-A Tech Forum @ Every 2 weeks from 16:00 to 17:00 on Thursday (BST) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-A Tech Forum We run an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Invites are via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: * Bill Fletcher- creator * tf-a(a)lists.trustedfirmware.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=NWlub3Ewdm1tMmk1cTJrM… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years

1
0
0 0

Upgrading libfdt library

by Madhukar Pappireddy

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

5 years

1
0
0 0

Re: [TF-A] ATF LTS version

by Varun Wadekar

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

5 years

1
0
0 0

Re: [TF-A] ATF LTS version

by Joanna Farley

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

5 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A