- TF-M - lists.trustedfirmware.org

TF-M static check for each patch has enabled on openCI

by Karl Zhang

Hi, The static check now enabled on openCI per the TF-M open tech forum discussion on 4th February 2021. The slides and video can be found from here<https://www.trustedfirmware.org/meetings/tf-m-technical-forum/>. Please let us know if you have any further concerns about the checks after enabled. A minor change to the slides is the cppcheck version has updated from 1.81 to 2.3. Thanks Karl

5 years, 3 months

1
0
0 0

TF-M v1.3.0 approaching. Code freeze heads up.

by Anton Komlev

Hi, TF-Mv1.3.0 release is approaching, planned for the end of March. TF-M code repository is to be freeze on March 18th, and tagged by TF-Mv1.3.0-RC1. Please plan you work accordingly and push your changes before the date. Thanks, Anton

5 years, 3 months

1
0
0 0

Technical Forum call - March 18

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, March 18 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 3 months

1
0
0 0

Re: [TF-M] Profile Large design document for review

by David Hu

Hi all, I'd like to merge Profile Large design this Thursday if no further comment. Since there are other TF-M major features under development in parallel, Profile Large design will be updated later when other major features are available. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Monday, March 1, 2021 10:30 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Profile Large design document for review Hi all, Can I ask for your comments on the TF-M Profile Large design document? TF-M Profile Large is one of TF-M Profiles. Profile Medium and Profile Small have been supported in TF-M. The document can be reviewed via https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8546/1/docs/…. Any comment is welcome! Best regards, Hu Ziji

5 years, 3 months

1
0
0 0

Re: [TF-M] Security vulnerability notice - SVC handler fetches incorrect caller stack pointer under specific cases.

by Kumar Gala

Agreed, I think it's a great thing for the SC to take up and make a policy on. Will add 2 cents: * Being a security focused project, I think its import that at least there is a patch release for the most recent officially released version, regardless of when the next release of TFM might be released. * Maybe looking at what policy a project like mbedtls has as a starting point. - k > On Mar 5, 2021, at 12:34 PM, Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Kumar, All, > > Thanks for bringing this topic up. > At the moment there is no plan for issuing the release v1.2.1 because of lack of policy for such hot fix releases. The release policy upgrade proposal shall be reviewed and agreed in the Steering Committee with the main questions: > 1. What is the hot fix baseline? > 2. What is the testing scope of the fix? > 3. On which platform(s) the fix shall be tested? > > The policy is under discussion and the community input is welcome. Please share your thoughts on the topic. > > The release v1.3.0 is expected by end of March-beginning of April, which will include the fix. > > Thanks, > Anton > > > -----Original Message----- > From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M > Sent: Friday, March 5, 2021 5:36 PM > To: Ken Liu <Ken.Liu(a)arm.com> > Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org > Subject: Re: [TF-M] Security vulnerability notice - SVC handler fetches incorrect caller stack pointer under specific cases. > > > >> On Mar 5, 2021, at 9:28 AM, Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: >> >> Hi Everyone, >> >> There is a new security vulnerability reported about the SVC handler fetches a wrong caller stack pointer under specific cases, which impacts the subsequent execution. >> >> Please find the security advisory specific to TF-M and patches that have been developed as per the TrustedFirmware.org security process[1] below : >> >> 1. TF-M Security advisory: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9005 >> 2. Fix based on the latest master has been merged into TF-M repo. The patch also can be found in Gerrit:https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8575 and https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8576. >> >> Please let us know if you have any comments. >> >> BR >> >> /Ken Liu >> >> [1] https://developer.trustedfirmware.org/w/collaboration/security_center/repor… >> -- >> TF-M mailing list >> TF-M(a)lists.trustedfirmware.org >> https://lists.trustedfirmware.org/mailman/listinfo/tf-m > > Is there plans for a security release of TFM v1.2 with this fix? > > - k > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 3 months

1
0
0 0

Re: [TF-M] Security vulnerability notice - SVC handler fetches incorrect caller stack pointer under specific cases.

by Anton Komlev

Hi Kumar, All, Thanks for bringing this topic up. At the moment there is no plan for issuing the release v1.2.1 because of lack of policy for such hot fix releases. The release policy upgrade proposal shall be reviewed and agreed in the Steering Committee with the main questions: 1. What is the hot fix baseline? 2. What is the testing scope of the fix? 3. On which platform(s) the fix shall be tested? The policy is under discussion and the community input is welcome. Please share your thoughts on the topic. The release v1.3.0 is expected by end of March-beginning of April, which will include the fix. Thanks, Anton -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M Sent: Friday, March 5, 2021 5:36 PM To: Ken Liu <Ken.Liu(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Security vulnerability notice - SVC handler fetches incorrect caller stack pointer under specific cases. > On Mar 5, 2021, at 9:28 AM, Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Everyone, > > There is a new security vulnerability reported about the SVC handler fetches a wrong caller stack pointer under specific cases, which impacts the subsequent execution. > > Please find the security advisory specific to TF-M and patches that have been developed as per the TrustedFirmware.org security process[1] below : > > 1. TF-M Security advisory: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9005 > 2. Fix based on the latest master has been merged into TF-M repo. The patch also can be found in Gerrit:https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8575 and https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8576. > > Please let us know if you have any comments. > > BR > > /Ken Liu > > [1] https://developer.trustedfirmware.org/w/collaboration/security_center/repor… > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m Is there plans for a security release of TFM v1.2 with this fix? - k -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 3 months

1
0
0 0

Re: [TF-M] Security vulnerability notice - SVC handler fetches incorrect caller stack pointer under specific cases.

by Kumar Gala

> On Mar 5, 2021, at 9:28 AM, Ken Liu via TF-M <tf-m(a)lists.trustedfirmware.org> wrote: > > Hi Everyone, > > There is a new security vulnerability reported about the SVC handler fetches a wrong caller stack pointer under specific cases, which impacts the subsequent execution. > > Please find the security advisory specific to TF-M and patches that have been developed as per the TrustedFirmware.org security process[1] below : > > 1. TF-M Security advisory: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9005 > 2. Fix based on the latest master has been merged into TF-M repo. The patch also can be found in Gerrit:https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8575 and https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8576. > > Please let us know if you have any comments. > > BR > > /Ken Liu > > [1] https://developer.trustedfirmware.org/w/collaboration/security_center/repor… > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m Is there plans for a security release of TFM v1.2 with this fix? - k

5 years, 3 months

1
0
0 0

Security vulnerability notice - SVC handler fetches incorrect caller stack pointer under specific cases.

by Ken Liu

Hi Everyone, There is a new security vulnerability reported about the SVC handler fetches a wrong caller stack pointer under specific cases, which impacts the subsequent execution. Please find the security advisory specific to TF-M and patches that have been developed as per the TrustedFirmware.org security process[1] below : 1. TF-M Security advisory: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9005 2. Fix based on the latest master has been merged into TF-M repo. The patch also can be found in Gerrit: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8575 and https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8576. Please let us know if you have any comments. BR /Ken Liu [1] https://developer.trustedfirmware.org/w/collaboration/security_center/repor…

5 years, 3 months

1
0
0 0

Re: [TF-M] Technical Forum call - March 4

by Anton Komlev

The agenda for the forum tomorrow: 1. CMSIS Pack for TF-M v1.2 presentation 2. AOB Thanks, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Monday, March 1, 2021 11:58 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - March 4 Hi, The next Technical Forum is planned on Thursday, March 4, 07:00-08:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 4 months

1
0
0 0

Re: [TF-M] Review on Firmware Update service in TF-M

by Sherry Zhang

Hi, Add some technical details. The newly added Firmware Update service provides the functionality of updating firmware images. It provides a standard interface for updating firmware and it is designed as platform/bootloader independent. The nonsecure application can call this service to achieve the firmware update by integrating TF-M with, for example, OTA library in the nonsecure side. The implementation provides a shim layer between the bootloader and the firmware update partition. Other bootloaders besides MCUboot should be easily ported with this partition. Any comment is very welcomed! Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Sherry Zhang via TF-M Sent: Monday, January 18, 2021 1:52 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Review on Firmware Update service in TF-M Hi, I created the patchset of adding the Firmware Update service in TF-M feature branch. I would like to ask you to review this patchset if you are interested in it. Top of the patchset: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7883 Regards, Sherry Zhang

5 years, 4 months

1
1
0 0

Deprecation of the nRF5340 PDK platform

by Głąbek, Andrzej

Hello, I would like to propose the deprecation of the nRF5340 PDK platform (nordic_nrf/nrf5340pdk_nrf5340_cpuapp) and the removal of this platform after the v1.3.0 release. The nRF5340 PDK is a preview development kit with an early revision (Engineering A) of the nRF5340 SoC and it has been replaced by the nRF5340 DK (as indicated here: https://www.nordicsemi.com/Software-and-tools/Development-Kits/nRF5340-PDK), which is also supported by TF-M. As per the process, should you have any objections to this deprecation, please respond to this proposal within 4 weeks. Best regards, Andrzej Głąbek

5 years, 4 months

1
0
0 0

Re: [TF-M] Please update TFM_TEST_REPO_VERSION

by David Hu

Hi Thomas, Sorry for the trouble. Could you let me know whether this change brought some problems or it fixed something? Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Friday, February 26, 2021 6:03 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Please update TFM_TEST_REPO_VERSION For some reason it seems that IAR is the only toolchain affected by: https://git.trustedfirmware.org/TF-M/tf-m-tests.git/commit/app/main_ns.c?id… Can we please update update the version to at least 4ae00fe? Cheers, Thomas -- Thomas Törnblom, Product Engineer IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com<mailto:thomas.tornblom@iar.com> Website: www.iar.com<http://www.iar.com> Twitter: www.twitter.com/iarsystems<http://www.twitter.com/iarsystems>

5 years, 4 months

2
7
0 0

Technical Forum call - March 4

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, March 4, 07:00-08:00 UTC (Asia time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 4 months

1
0
0 0

Profile Large design document for review

by David Hu

Hi all, Can I ask for your comments on the TF-M Profile Large design document? TF-M Profile Large is one of TF-M Profiles. Profile Medium and Profile Small have been supported in TF-M. The document can be reviewed via https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8546/1/docs/…. Any comment is welcome! Best regards, Hu Ziji

5 years, 4 months

1
0
0 0

Please update TFM_TEST_REPO_VERSION

by Thomas Törnblom

For some reason it seems that IAR is the only toolchain affected by: https://git.trustedfirmware.org/TF-M/tf-m-tests.git/commit/app/main_ns.c?id… Can we please update update the version to at least 4ae00fe? Cheers, Thomas -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

5 years, 4 months

1
0
0 0

Re: [TF-M] TF-M git repo normalization

by Kevin Peng

Hi all, Please be noted that both of the patches have been merged: TF-M: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8283 tf-m-tools: https://review.trustedfirmware.org/c/TF-M/tf-m-tools/+/8484 Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: Friday, February 19, 2021 1:47 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M git repo normalization Hi all, As I mentioned on yesterday's forum, I made a patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tools/+/8484> to fix the gitattributes issues in the tools repo. And the last call of review for the main repo normalization: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8283 Plan to have them both merged on next Tuesday. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: Tuesday, February 9, 2021 10:03 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@arm.com>> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M git repo normalization Hi, I'd like to give a brief introduction on the git normalization before merging this patch. @Anton Komlev<mailto:Anton.Komlev@arm.com>, can I reserve 15-20 minutes of the next tech forum? Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: Monday, February 8, 2021 10:56 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M git repo normalization Hi all, Would like to merge the below patch *tomorrow* if there were no objections. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: Friday, February 5, 2021 10:37 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M git repo normalization This patch was generated by git command automatically: $ git add --renormalize . It does change any contents of the files, except the line-endings in the repository. Your existing local working tree should not be affected when you pick up it or later when it's merged. The only file maintained manually is the .gitattributes Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: Friday, February 5, 2021 9:53 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M git repo normalization Hi all, Following the git normalization topic of the tech forum yesterday, I checked TF-M. It has not been enabled the git normalization feature. I've made a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8283> to make this happen. Please check out or rebase your work upon this patch to see any issues. Your existing working tree should not be affected regarding the line-endings. What is the normalization? To be simple, different developers on different Host OS can have different line-endings in their local working tree and do not need to worry about interference with each other. Reference: https://git-scm.com/docs/gitattributes Best Regards, Kevin

5 years, 4 months

1
0
0 0

Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification

by Andrew Thoelke

I've had some further input on the interrupt management API. The use of patterns such as: bool irq_enabled = psa_irq_is_enabled(MY_IRQ); // [1] psa_irq_disable(MY_IRQ); // [2] // critical section if (irq_enabled) psa_irq_enable(MY_IRQ); must be discouraged as this is not guaranteed to be safe in the presence of interrupts that can change the status of MY_IRQ between the query [1] and the disable [2]. In general, it requires whole system analysis to determine that there are no such interrupts, and that this code is 100% reliable. However, providing the originally proposed API such as psa_irq_disable(), which returns the prior status, does not practically solve the problem. Instead, it just moves the race condition window into the implementation of that API. The only way in which such an API would be generally safe from the race condition is if the query+disable is atomic with respect to all other interrupts in the system - this either requires disabling interrupts entirely, or having an atomic read+disable capability in the interrupt controller. In systems which worry about such race conditions, disabling all interrupts can be unacceptable. The recommended approach is to avoid having software that depends on the state of the interrupt, but which does not implicitly know the state of the interrupt. In such a system, there is never a need to query the current interrupt state as on any line of code, the interrupt state is always known at design time. I am not sure if this suggests that we should: 1. Remove even the psa_irq_is_enabled() function, to prevent developers writing the above code, OR 2. We do not document the above pattern as a way to manage nested critical sections, OR 3. Retain the example above, but explain that this must be coupled with a software design that ensures the stability of the MY_IRQ status between [1] and [2]? Regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 22 February 2021 04:49 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification As the ‘psa_irq_status_t’ is a implementation-defined value, is it possible let the implementation-define the status encoding? Then the status and its checking code needs to be define by implementation, too: PSA_IRQ_STATUS_NOCHANGE PSA_IRQ_STATUS_DISABLE PSA_IRQ_STATUS_ENABLE PSA_IRQ_STAUTS_IS_ENABLED(status) This would make everything implementation-defined and this affects the headers, and one extra header: psa_impdef.h needs to be created by implementations. With this the ffm based applications just use preprocessors to get status and check them; the enable/disable can be out of ‘true’ and ‘false’ values. /Ken From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: Tuesday, January 26, 2021 11:08 AM To: mailto:tf-m@lists.trustedfirmware.org Cc: nd <mailto:nd@arm.com> Subject: Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification Hi all, Per the off-line discussion with Andrew, I’d like to start a wider discussion on the interrupt APIs, specifically the Secure Partition API changes for interrupt control in chapter 6.3.3. There are the following APIs: • uint32_t psa_irq_is_enabled (psa_signal_t irq_signal); This API returns 0 if the interrupt is disabled and 1 if the interrupt is enabled. • psa_irq_status_t psa_irq_disable(psa_signal_t irq_signal); This API returns the status of the interrupt prior to this call with an implementation defined value Note the return type of the interrupt status is different. The first one is only to tell whether the interrupt is enabled (1) or not (0) – an equivalent to bool type. The second one could be any value to indicate an interrupt status. And that value is intended to be passed to psa_irq_restore to write to the interrupt control register directly. • void psa_irq_restore(psa_signal_t irq_signal, psa_irq_status_t saved_status); The typical usage: psa_irq_status irq2_state = psa_irq_disable(IRQ2_SIGNAL) ; // manipulate data shared with IRQ2 … psa_irq_restore(IRQ2_SIGNAL, irq2_state); This is a very efficient design as the 'saved status value' can be the exact value that needs to be written to an interrupt control register to restore the previous state. But TF-M seems to be unable to take that advantage. Because the most common interrupt controller is the NVIC provided by the core. The NVIC takes 1/0 to enable or disable the interrupt and one register for 32 interrupts. The underlying NVIC operation provided by CMSIS is NVIC_Enable/DisableIRQ. So the psa_irq_status_t in TF-M would simply 1 or 0 for a specific interrupt signal. Then the psa_irq_restore could be unnecessary if psa_irq_disable returns uint32_t just like psa_irq_is_enabled: uint32_t irq_status = psa_irq_disable(IRQ); ... // critical section if (irq_status) psa_irq_enable(IRQ); Any thoughts on the necessity of the psa_irq_restore API? The draft implementation of the current APIs for easy understanding: https://review.trustedfirmware.org/q/topic:%22psa_interrupt_api%22+(status:… Best Regards, Kevin -----Original Message----- From: TF-M <mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M Sent: Friday, January 15, 2021 1:25 AM To: mailto:tf-m@lists.trustedfirmware.org; nd <mailto:nd@arm.com> Subject: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification Hi all, The PSA Firmware Framework for M 1.1 Extensions specification is now published on Arm Developer. This document introduces a set of updates and extensions to the Arm® Platform Security Architecture Firmware Framework (FF-M) specification, designed to build on the capabilities provided in version 1.0. This is an initial ALPHA release in order to enable wider review and feedback on the changes proposed to be included in the v1.1 specification. At this quality level, the changes and interfaces defined are not stable enough for product development. When the proposed extensions are sufficiently stable to be classed as Beta, they will be integrated into the FF-M version 1.1 specification. The 1.1 Extensions document can be downloaded from: https://developer.arm.com/documentation/aes0039/latest Both the 1.0 Specification and the 1.1 Extensions document are linked from the main PSA architecture page: https://developer.arm.com/architectures/security-architectures/platform-sec… Ken and I have presented a number of times at last year's Tech Forums on the proposals in the specification, most recently I provided a summary of the whole document on 10th December 2020. If you have any feedback, please provide it to mailto:arm.psa-feedback@arm.com, or discuss the proposals here in the TF-M mailing list. Regards, Andrew -- TF-M mailing list mailto:TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 4 months

1
0
0 0

Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification

by Ken Liu

As the ‘psa_irq_status_t’ is a implementation-defined value, is it possible let the implementation-define the status encoding? Then the status and its checking code needs to be define by implementation, too: PSA_IRQ_STATUS_NOCHANGE PSA_IRQ_STATUS_DISABLE PSA_IRQ_STATUS_ENABLE PSA_IRQ_STAUTS_IS_ENABLED(status) This would make everything implementation-defined and this affects the headers, and one extra header: psa_impdef.h needs to be created by implementations. With this the ffm based applications just use preprocessors to get status and check them; the enable/disable can be out of ‘true’ and ‘false’ values. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: Tuesday, January 26, 2021 11:08 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification Hi all, Per the off-line discussion with Andrew, I’d like to start a wider discussion on the interrupt APIs, specifically the Secure Partition API changes for interrupt control in chapter 6.3.3. There are the following APIs: * uint32_t psa_irq_is_enabled (psa_signal_t irq_signal); This API returns 0 if the interrupt is disabled and 1 if the interrupt is enabled. * psa_irq_status_t psa_irq_disable(psa_signal_t irq_signal); This API returns the status of the interrupt prior to this call with an implementation defined value Note the return type of the interrupt status is different. The first one is only to tell whether the interrupt is enabled (1) or not (0) – an equivalent to bool type. The second one could be any value to indicate an interrupt status. And that value is intended to be passed to psa_irq_restore to write to the interrupt control register directly. * void psa_irq_restore(psa_signal_t irq_signal, psa_irq_status_t saved_status); The typical usage: psa_irq_status irq2_state = psa_irq_disable(IRQ2_SIGNAL) ; // manipulate data shared with IRQ2 … psa_irq_restore(IRQ2_SIGNAL, irq2_state); This is a very efficient design as the 'saved status value' can be the exact value that needs to be written to an interrupt control register to restore the previous state. But TF-M seems to be unable to take that advantage. Because the most common interrupt controller is the NVIC provided by the core. The NVIC takes 1/0 to enable or disable the interrupt and one register for 32 interrupts. The underlying NVIC operation provided by CMSIS is NVIC_Enable/DisableIRQ. So the psa_irq_status_t in TF-M would simply 1 or 0 for a specific interrupt signal. Then the psa_irq_restore could be unnecessary if psa_irq_disable returns uint32_t just like psa_irq_is_enabled: uint32_t irq_status = psa_irq_disable(IRQ); ... // critical section if (irq_status) psa_irq_enable(IRQ); Any thoughts on the necessity of the psa_irq_restore API? The draft implementation of the current APIs for easy understanding: https://review.trustedfirmware.org/q/topic:%22psa_interrupt_api%22+(status:… Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Andrew Thoelke via TF-M Sent: Friday, January 15, 2021 1:25 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification Hi all, The PSA Firmware Framework for M 1.1 Extensions specification is now published on Arm Developer. This document introduces a set of updates and extensions to the Arm® Platform Security Architecture Firmware Framework (FF-M) specification, designed to build on the capabilities provided in version 1.0. This is an initial ALPHA release in order to enable wider review and feedback on the changes proposed to be included in the v1.1 specification. At this quality level, the changes and interfaces defined are not stable enough for product development. When the proposed extensions are sufficiently stable to be classed as Beta, they will be integrated into the FF-M version 1.1 specification. The 1.1 Extensions document can be downloaded from: https://developer.arm.com/documentation/aes0039/latest Both the 1.0 Specification and the 1.1 Extensions document are linked from the main PSA architecture page: https://developer.arm.com/architectures/security-architectures/platform-sec… Ken and I have presented a number of times at last year's Tech Forums on the proposals in the specification, most recently I provided a summary of the whole document on 10th December 2020. If you have any feedback, please provide it to arm.psa-feedback(a)arm.com<mailto:arm.psa-feedback@arm.com>, or discuss the proposals here in the TF-M mailing list. Regards, Andrew -- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 4 months

1
0
0 0

Re: [TF-M] Bug in GNU Arm Embedded toolchain (version 10-2020-q4-major) for TFM

by David Hu

Hi Kumar, Thanks a lot for reporting this issue. We had also reported it to the GNU toolchain team and were waiting them to make it public. Hi all, Now the details of this issue can be found in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99157. AFIAK, there is no workaround for this issue yet, without modifying the GNU toolchain source code. So I'd like to suggest to *not* use GNU Arm embedded toolchain version 10-2020-q4-major now. The earlier versions are not affected. Best regards, Hu Ziji -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kumar Gala via TF-M Sent: Friday, February 19, 2021 2:41 AM To: Adrian Shaw via TF-M <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Bug in GNU Arm Embedded toolchain (version 10-2020-q4-major) for TFM Be aware that the binary release of the GNU Arm embedded toolchain version 10-2020-q4-major has a bug in it that impacts TFM support. I’ve reported this to the Arm team that works on the toolchain and provided a fix as well. The libgcc/cmse.o code isn’t being properly compiled and thus doesn’t work correctly. I’ve made the fix in the Zephyr SDK toolchain that provides an Arm embedded build: https://github.com/zephyrproject-rtos/sdk-ng Bug fix here: https://github.com/zephyrproject-rtos/sdk-ng/blob/master/patches/gcc/10.2.0… - k -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 4 months

1
0
0 0

Re: [TF-M] TF-M git repo normalization

by Kevin Peng

Hi all, As I mentioned on yesterday's forum, I made a patch<https://review.trustedfirmware.org/c/TF-M/tf-m-tools/+/8484> to fix the gitattributes issues in the tools repo. And the last call of review for the main repo normalization: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8283 Plan to have them both merged on next Tuesday. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Kevin Peng via TF-M Sent: Tuesday, February 9, 2021 10:03 AM To: tf-m(a)lists.trustedfirmware.org; Anton Komlev <Anton.Komlev(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M git repo normalization Hi, I'd like to give a brief introduction on the git normalization before merging this patch. @Anton Komlev<mailto:Anton.Komlev@arm.com>, can I reserve 15-20 minutes of the next tech forum? Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: Monday, February 8, 2021 10:56 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M git repo normalization Hi all, Would like to merge the below patch *tomorrow* if there were no objections. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: Friday, February 5, 2021 10:37 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: Re: [TF-M] TF-M git repo normalization This patch was generated by git command automatically: $ git add --renormalize . It does change any contents of the files, except the line-endings in the repository. Your existing local working tree should not be affected when you pick up it or later when it's merged. The only file maintained manually is the .gitattributes Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Kevin Peng via TF-M Sent: Friday, February 5, 2021 9:53 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] TF-M git repo normalization Hi all, Following the git normalization topic of the tech forum yesterday, I checked TF-M. It has not been enabled the git normalization feature. I've made a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8283> to make this happen. Please check out or rebase your work upon this patch to see any issues. Your existing working tree should not be affected regarding the line-endings. What is the normalization? To be simple, different developers on different Host OS can have different line-endings in their local working tree and do not need to worry about interference with each other. Reference: https://git-scm.com/docs/gitattributes Best Regards, Kevin

5 years, 4 months

1
0
0 0

Bug in GNU Arm Embedded toolchain (version 10-2020-q4-major) for TFM

by Kumar Gala

Be aware that the binary release of the GNU Arm embedded toolchain version 10-2020-q4-major has a bug in it that impacts TFM support. I’ve reported this to the Arm team that works on the toolchain and provided a fix as well. The libgcc/cmse.o code isn’t being properly compiled and thus doesn’t work correctly. I’ve made the fix in the Zephyr SDK toolchain that provides an Arm embedded build: https://github.com/zephyrproject-rtos/sdk-ng Bug fix here: https://github.com/zephyrproject-rtos/sdk-ng/blob/master/patches/gcc/10.2.0… - k

5 years, 4 months

1
0
0 0

Re: [TF-M] Technical Forum call - February 18

by Anton Komlev

Agenda for the forum: 1. Git repository normalization. 2. Linaro SQUAD interface to visualise TF-M metrics 3. Any Other Business Regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 10 February 2021 17:14 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - February 18 Hello, The next Technical Forum is planned on Thursday, Feb 18 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Kevin Peng already proposed the one: 1. Git repository normalization. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 4 months

1
0
0 0

Firmware Update API specification

by Adrian Shaw

Hi all, The PSA Firmware Update API specification is now published on Arm Developer. This document introduces a standard firmware interface for installing firmware updates. The document can be downloaded from https://developer.arm.com/documentation/ihi0093/0000/ This is an initial BETA release in order to enable wider review and feedback. We shall release new Beta versions to address feedback and comments. Sherry Zhang in TF-M has begun an implementation of this interface, which is a work in progress. If you have any feedback about the API specification, please provide it to arm.psa-feedback(a)arm.com, or discuss the proposal here in the TF-M mailing list. Regards, Adrian

5 years, 4 months

1
0
0 0

Technical Forum call - February 18

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, Feb 18 at 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Kevin Peng already proposed the one: 1. Git repository normalization. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 4 months

1
0
0 0

Re: [TF-M] PSA-ARCH-TEST with zephyr

by David Hu

Hi Antonio, May I suggest to raise the question to PSA Arch test repo https://github.com/ARM-software/psa-arch-tests/issues? Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Antonio Ken IANNILLO via TF-M Sent: Wednesday, February 10, 2021 8:43 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] PSA-ARCH-TEST with zephyr I just add the verbosity (I initially tough was the cmake verbosity..) to the test libraries. This is the new output is somebody can help: https://pastebin.com/JNQ6TD0K In the specific the failure is at : ‘’’ TEST: 403 | DESCRIPTION: Insufficient space check Input id is 01030000 Input id is 01030000 Input id is 02020000 Input id is 02020000 [Info] Executing tests from non-secure [Info] Executing PS tests [Check 1] Overload storage space Setting 0x00000200 bytes for UID 5 Setting 0x00000200 bytes for UID 6 Setting 0x00000200 bytes for UID 7 Setting 0x00000200 bytes for UID 8 Setting 0x00000200 bytes for UID 9 Setting 0x00000200 bytes for UID 10 Setting 0x00000200 bytes for UID 11 Setting 0x00000200 bytes for UID 12 Setting 0x00000200 bytes for UID 13 UID 13 set failed due to insufficient space Remove all registered UIDs Removing UID 5 Removing UID 6 Removing UID 7 Removing UID 8 Removing UID 9 Removing UID 10 Removing UID 11 Removing UID 12 [Check 2] Overload storage again to verify all previous UID removed Setting 0x00000200 bytes for UID 5 Setting 0x00000200 bytes for UID 6 Setting 0x00000200 bytes for UID 7 Setting 0x00000200 bytes for UID 8 Setting 0x00000200 bytes for UID 9 [INF] Starting bootloader [INF] Swap type: none [INF] Swap type: none [INF] Bootloader chainload address offset: 0x80000 [INF] Jumping to the first image slot [Sec Thread] Secure image initializing! Booting TFM v1.2.0 [Crypto] MBEDTLS_TEST_NULL_ENTROPY is not suitable for production! *** Booting Zephyr OS build v2.5.0-rc1-209-g30634334a811 *** ‘’’ -- Antonio Ken Iannillo

5 years, 4 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M