- TF-M - lists.trustedfirmware.org

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

4 years, 1 month

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

4 years, 1 month

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

4 years, 1 month

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

4 years, 1 month

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

4 years, 1 month

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…

4 years, 1 month

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

4 years, 1 month

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

4 years, 1 month

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

4 years, 1 month

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>

4 years, 1 month

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

4 years, 1 month

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

4 years, 1 month

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>

4 years, 2 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

4 years, 2 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

4 years, 2 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

4 years, 2 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

4 years, 2 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

4 years, 2 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

4 years, 2 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

4 years, 2 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

4 years, 2 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

4 years, 2 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

4 years, 2 months

1
0
0 0

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

by Antonio Ken IANNILLO

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

4 years, 2 months

1
0
0 0

Re: [TF-M] Boot data usage

by Ken Liu

Thanks for your inputs. I am seeking if boot data is used for a specific service only - if that is true, this boot data actually can be bound to the specific services, and other could request boot data related services by API. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: Tuesday, February 9, 2021 8:53 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Boot data usage Hello, On STM platform, The boot data is also used to pass specific information to user different from attestation. For this support a specific Major is used. The actual implementation available in ST cube needs to be reworked so that each platform can customize it (Major value, and table checking access control on tfm core) Best regards From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Tamas Ban via TF-M Sent: mardi 9 février 2021 11:52 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] Boot data usage Hi Ken, AFAIK current implementation of FWU partition also relies on shared data received from bootloader. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 2021. február 9., kedd 10:47 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] Boot data usage Hi, Wondered if someone is expanding the boot data usage, as the default user is attestation only. Please provide your case if you are expanding boot data usage. Thanks! /Ken

4 years, 2 months

1
0
0 0

PSA-ARCH-TEST with zephyr

by Antonio Ken IANNILLO

Dear all, I’m running the PSA-ARCH-TEST (functional api tests) with Zephyr OS (for now emulated with QEMU 5). I followed the instructions to build the test libraries and linked successfully with an easy zephyr application (it just call the val_entry() function). When everything seems working smoothly with Storage tests, I realized that at a certain point the system fails and restarts. Repeatedly. Does any of you have already integrated these tests with zephyr? Did I forget something in the process? I tried also to understand the test that failed everything. It actually overload storage space (without any problem) and do it again (fails after 6 UIDS). Further, any of you know how to have a debug version of the psa-arch-test libraries? Or how to force them to print debug/test message as well… Terminal output is here: https://pastebin.com/ixmeB0kN Thank you very much for your help, -- Antonio Ken Iannillo Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 www.uni.lu/snt https://akiannillo.github.io/

4 years, 2 months

1
0
0 0

Re: [TF-M] Boot data usage

by Michel JAOUEN

Hello, On STM platform, The boot data is also used to pass specific information to user different from attestation. For this support a specific Major is used. The actual implementation available in ST cube needs to be reworked so that each platform can customize it (Major value, and table checking access control on tfm core) Best regards From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Tamas Ban via TF-M Sent: mardi 9 février 2021 11:52 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Boot data usage Hi Ken, AFAIK current implementation of FWU partition also relies on shared data received from bootloader. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Ken Liu via TF-M Sent: 2021. február 9., kedd 10:47 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] Boot data usage Hi, Wondered if someone is expanding the boot data usage, as the default user is attestation only. Please provide your case if you are expanding boot data usage. Thanks! /Ken

4 years, 2 months

1
0
0 0

Re: [TF-M] Boot data usage

by Tamas Ban

Hi Ken, AFAIK current implementation of FWU partition also relies on shared data received from bootloader. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 2021. február 9., kedd 10:47 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Boot data usage Hi, Wondered if someone is expanding the boot data usage, as the default user is attestation only. Please provide your case if you are expanding boot data usage. Thanks! /Ken

4 years, 2 months

1
0
0 0

Boot data usage

by Ken Liu

Hi, Wondered if someone is expanding the boot data usage, as the default user is attestation only. Please provide your case if you are expanding boot data usage. Thanks! /Ken

4 years, 2 months

1
0
0 0

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

by Kevin Peng

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> On Behalf Of Kevin Peng via TF-M Sent: Monday, February 8, 2021 10:56 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)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

4 years, 2 months

1
0
0 0

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

by Kevin Peng

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> On Behalf Of Kevin Peng via TF-M Sent: Friday, February 5, 2021 10:37 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)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

4 years, 2 months

1
0
0 0

[RFC] Platform data adjustment

by Ken Liu

Hi, I have created a couple of patches to change the way to assemble the partitions, and start with the platform data: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8288 The basic idea is we would avoid using pointer to link data between partitions, as mentioned in one of the past tech forum topics: https://www.trustedfirmware.org/docs/TF-M_partition_storage_arrangement.pdf Please help to review this patch, especially the platform owners, as this change modifies almost all platform sources. Also, I just use a direct 'find and replace' so some of the copyright years are not updated. Would update them in subsequent small patches. Thanks. /Ken

4 years, 2 months

1
0
0 0

Re: [TF-M] Ask for final review on physical attack mitigation design

by David Hu

Hi all, The design document is merged as planned. Thanks a lot for your review! Any further comment or suggestion is always comment. 😊 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Monday, February 1, 2021 4:01 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Ask for final review on physical attack mitigation design Hi all, I’d like to merge the design document of physical attack mitigation in TF-M this week if no further comment. May I ask you to take another look at the following document patch? https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7476 Best regards, Hu Ziji

4 years, 2 months

1
0
0 0

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

by Kevin Peng

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> On Behalf Of Kevin Peng via TF-M Sent: Friday, February 5, 2021 9:53 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)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

4 years, 2 months

1
0
0 0

TF-M git repo normalization

by Kevin Peng

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

4 years, 2 months

1
0
0 0

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

by Anton Komlev

Hi, Looks like we have an empty agenda for tomorrow's forum. Let's use the time for the free discussion on any TF-M topic. Please raise questions / issues / improvements worth to be discussed within the community. See you, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 28 January 2021 13:29 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - February 4 Hello, The next Technical Forum is planned on Thursday, Feb 4 at 7:00-8: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

4 years, 2 months

1
0
0 0

Re: [TF-M] NXP lpcxpresso55s69 appears broken

by Jamie Fox

Hi Thomas, Sorry about that. I have reproduced the issue on AN521 by copying over the lpcxpresso55s69 storage config. I'll investigate a fix on that platform, but will need you to verify it for me afterwards as I don't have that platform. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 03 February 2021 13:30 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] NXP lpcxpresso55s69 appears broken Looks like this is the commit that breaks the nxp/lpcxpresso55s69 support: --- PS C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m> git bisect good 6a3946aa017fa4da3953a825991f8ce755114637 is the first bad commit commit 6a3946aa017fa4da3953a825991f8ce755114637 Author: Jamie Fox <jamie.fox(a)arm.com><mailto:jamie.fox@arm.com> Date: Mon Dec 7 21:50:31 2020 +0000 Platform: TF-M ITS and PS HAL ... --- Den 2021-02-03 kl. 13:54, skrev Thomas Törnblom via TF-M: I have just fixed an IAR linking issue for the nxp/lpcxpresso55s69, see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8251 I tried using the current sources, but it seems that there is some issues causing the board to run into a hard fault when built with GNUARM. Not sure what commit caused the breakage. 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> -- 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>

4 years, 2 months

2
1
0 0

Re: [TF-M] NXP lpcxpresso55s69 appears broken

by Kevin Townsend

Hi Jamie, I’ll be happy to test here as well if you add me to the change request. Best regards, Kevin On Wed, 3 Feb 2021 at 16:10, Jamie Fox via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi Thomas, > > > > Sorry about that. I have reproduced the issue on AN521 by copying over the > lpcxpresso55s69 storage config. I’ll investigate a fix on that platform, > but will need you to verify it for me afterwards as I don’t have that > platform. > > > > Kind regards, > > Jamie > > > > *From:* TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of *Thomas > Törnblom via TF-M > *Sent:* 03 February 2021 13:30 > *To:* tf-m(a)lists.trustedfirmware.org > *Subject:* Re: [TF-M] NXP lpcxpresso55s69 appears broken > > > > Looks like this is the commit that breaks the nxp/lpcxpresso55s69 support: > --- > PS C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m> git bisect good > 6a3946aa017fa4da3953a825991f8ce755114637 is the first bad commit > commit 6a3946aa017fa4da3953a825991f8ce755114637 > Author: Jamie Fox <jamie.fox(a)arm.com> <jamie.fox(a)arm.com> > Date: Mon Dec 7 21:50:31 2020 +0000 > > Platform: TF-M ITS and PS HAL > ... > --- > > Den 2021-02-03 kl. 13:54, skrev Thomas Törnblom via TF-M: > > I have just fixed an IAR linking issue for the nxp/lpcxpresso55s69, see > https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8251 > > I tried using the current sources, but it seems that there is some issues > causing the board to run into a hard fault when built with GNUARM. > > Not sure what commit caused the breakage. > > 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 Website: www.iar.com > Twitter: www.twitter.com/iarsystems > > > > > > -- > > *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 Website: www.iar.com > Twitter: www.twitter.com/iarsystems > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

4 years, 2 months

1
0
0 0

Re: [TF-M] NXP lpcxpresso55s69 appears broken

by Thomas Törnblom

Looks like this is the commit that breaks the nxp/lpcxpresso55s69 support: --- PS C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m> git bisect good 6a3946aa017fa4da3953a825991f8ce755114637 is the first bad commit commit 6a3946aa017fa4da3953a825991f8ce755114637 Author: Jamie Fox <jamie.fox(a)arm.com> Date: Mon Dec 7 21:50:31 2020 +0000 Platform: TF-M ITS and PS HAL ... --- Den 2021-02-03 kl. 13:54, skrev Thomas Törnblom via TF-M: > I have just fixed an IAR linking issue for the nxp/lpcxpresso55s69, > see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8251 > > I tried using the current sources, but it seems that there is some > issues causing the board to run into a hard fault when built with GNUARM. > > Not sure what commit caused the breakage. > > 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> > -- *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>

4 years, 2 months

1
0
0 0

NXP lpcxpresso55s69 appears broken

by Thomas Törnblom

I have just fixed an IAR linking issue for the nxp/lpcxpresso55s69, see https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8251 I tried using the current sources, but it seems that there is some issues causing the board to run into a hard fault when built with GNUARM. Not sure what commit caused the breakage. 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>

4 years, 2 months

1
0
0 0

Ask for final review on physical attack mitigation design

by David Hu

Hi all, I'd like to merge the design document of physical attack mitigation in TF-M this week if no further comment. May I ask you to take another look at the following document patch? https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7476 Best regards, Hu Ziji

4 years, 2 months

1
0
0 0

Re: [TF-M] Fatal error handler in secure FW - review request

by Kevin Townsend

Oyvind, Thanks for putting this together. Looks quite useful, and saves some monotony debugging. I put together a similar script but as a Python function for GDB: https://gist.github.com/microbuilder/1677a27e4566a28b36a79f954f1dede6 ... having this in C, however, means you don't need to have a Python-enabled version of GDB. Best regards, Kevin On Fri, 29 Jan 2021 at 11:33, Rønningstad, Øyvind via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > Hi everyone > > I wanted to make it easier to debug HardFaults/BusFaults/SecureFaults in > TFM, since I’ve gotten quite a few of them while adding the nrf platforms. > > I have created a proposal in > https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7891 and > would like to get some comments on the general idea. > > The proposal gathers a number of different values, especially the ones > that are harder to retrieve in a debugger, like the fault status registers > in SCB. > > The values are placed in memory so they can be inspected in a debugger, > and if built with -DTFM_SPM_LOG_LEVEL=TFM_SPM_LOG_LEVEL_DEBUG they are also > printed. > > Here is an example of the printout: > > FATAL ERROR: HardFault > > Here is some context for the exception: > > EXC_RETURN (LR): 0xFFFFFFBD > > Exception came from non-secure FW in thread mode. > > MSP(_S): 0x200007F8 > > PSP(_S): 0x20000F28 > > Exception frame at: 0x200176D8 > > R0: 0x0000003E > > R1: 0x00000001 > > R2: 0x00000001 > > R3: 0xFFFFFFFF > > R12: 0x00000000 > > LR: 0x00050623 > > PC: 0x00050626 > > CFSR: 0x00000000 > > BFAR: Not Valid > > MMFAR: Not Valid > > HFSR: 0x40000000 > > SFSR: 0x00000000 > > SFAR: Not Valid > > > > BR, Øyvind Rønningstad > -- > TF-M mailing list > TF-M(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-m >

4 years, 2 months

1
0
0 0

Fatal error handler in secure FW - review request

by Rønningstad, Øyvind

Hi everyone I wanted to make it easier to debug HardFaults/BusFaults/SecureFaults in TFM, since I've gotten quite a few of them while adding the nrf platforms. I have created a proposal in https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7891 and would like to get some comments on the general idea. The proposal gathers a number of different values, especially the ones that are harder to retrieve in a debugger, like the fault status registers in SCB. The values are placed in memory so they can be inspected in a debugger, and if built with -DTFM_SPM_LOG_LEVEL=TFM_SPM_LOG_LEVEL_DEBUG they are also printed. Here is an example of the printout: FATAL ERROR: HardFault Here is some context for the exception: EXC_RETURN (LR): 0xFFFFFFBD Exception came from non-secure FW in thread mode. MSP(_S): 0x200007F8 PSP(_S): 0x20000F28 Exception frame at: 0x200176D8 R0: 0x0000003E R1: 0x00000001 R2: 0x00000001 R3: 0xFFFFFFFF R12: 0x00000000 LR: 0x00050623 PC: 0x00050626 CFSR: 0x00000000 BFAR: Not Valid MMFAR: Not Valid HFSR: 0x40000000 SFSR: 0x00000000 SFAR: Not Valid BR, Øyvind Rønningstad

4 years, 2 months

1
0
0 0

Technical Forum call - February 4

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, Feb 4 at 7:00-8: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

4 years, 3 months

1
0
0 0

Re: [TF-M] Is Musca-A deprecated already?

by Gyorgy Szing

Hi, Just a humble suggestion: capability could be added to cmake to generate a build environment manifest. This could be a JSON or simple text file listing the location and version of each dependency (tool or software). The manifest file could simplify tracking down similar issues. /George From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: 28 January 2021 08:38 To: Sherry Zhang <Sherry.Zhang2(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Is Musca-A deprecated already? Thanks Sherry, Appears the current "cysecuretools" has a dependency on imgtool 1.7.0a1, which is likely where it came from. I did build for musca_a last week and I may have updated cysecuretools since then as I had issues with flashing the psoc64, and that must have installed 1.7.0a1. I installed 1.7.1, which caused a dependency error on cysecuretools 3.0.0. Works now! Cheers, Thomas Den 2021-01-28 kl. 03:50, skrev Sherry Zhang: Hi Thomas, The issue is caused by the imgtool package itself. The version 1.7.0a1 is a pre-release version. If you check the line 378 of image.py of the imgtool package of version 1.7.0a1, it does not check the 'None' before accessing the custom_tlvs.items: [cid:image003.jpg@01D6F552.951E90A0] In the version of 1.7.1, it has added the 'None' check at line 389 in image.py: [cid:image004.jpg@01D6F552.951E90A0] In TF-M build system, the custom_tlvs should be 'None'. To solve your issue, I suggest you use a release version of the imgtool package, such as 1.7.1, other than a pre-release one. Please let me know how it goes. Regards, Sherry Zhang From: Thomas Törnblom <thomas.tornblom(a)iar.com><mailto:thomas.tornblom@iar.com> Sent: Wednesday, January 27, 2021 4:46 PM To: Sherry Zhang <Sherry.Zhang2(a)arm.com><mailto:Sherry.Zhang2@arm.com>; 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] Is Musca-A deprecated already? Hi Sherry, Looks like I have version 1.7.0a1. PS C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_iar> imgtool version 1.7.0a1 Cheers, Thomas Den 2021-01-27 kl. 09:22, skrev Sherry Zhang: Hi Thomas, Can you share the version of the imgtool package you used? The recommended version is >=1.6.0. We run the build command on Linux locally and it works well. An alternative option is to use the imgtool script from the upstream MCUBoot repo. To achieve that you can copy the folder ./build_dir/lib/ext/mcuboot-src/scripts/imgtool to bl2/ext/mcuboot/scripts/wrapper/. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Tï¿½rnblom via TF-M Sent: Wednesday, January 27, 2021 12:28 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Is Musca-A deprecated already? I'm working on some IAR brokenness for the cypress/psoc64 and for comparison I'm attempting to build for my favorite board, the musca_a, but it seems builds fails now. I think it was working last week, but today I'm unable to build with any of the toolchains. I get the following errors frmo all of them. Here's a gcc build: --- [629/629] Generating tfm_s_ns_signed.bin FAILED: bl2/ext/mcuboot/tfm_s_ns_signed.bin cmd.exe /C "cd /D C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_armclang\bl2\ext\mcuboot && C:\Users\thomasto\AppData\Local\Programs\Python\Python39\python.exe C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.2.0 --layout C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/./signing_layout_s_ns.o -k C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin && "C:\Program Files\CMake\bin\cmake.exe" -E copy C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bin" Traceback (most recent call last): File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 126, in <module> wrap() File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 829, in __call__ return self.main(*args, **kwargs) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 782, in main rv = self.invoke(ctx) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 1066, in invoke return ctx.invoke(self.callback, **ctx.params) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 610, in invoke return callback(*args, **kwargs) File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 121, in wrap img.create(key, public_key_format, enckey, dependencies, boot_record) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\imgtool\image.py", line 378, in create for tag, value in custom_tlvs.items(): AttributeError: 'NoneType' object has no attribute 'items' ninja: build stopped: subcommand failed. --- cmake line: cmake -GNinja -S .. -B . -DTFM_PLATFORM=musca_a "-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DMCUBOOT_LOG_LEVEL=DEBUG -DTFM_PSA_API=ON I've tested building for several of the other targets, which seems to work, but I don't have any of these here. Ideas? Thanks, 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> -- 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> -- 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>

4 years, 3 months

1
0
0 0

Re: [TF-M] Is Musca-A deprecated already?

by Sherry Zhang

Hi Thomas, Can you share the version of the imgtool package you used? The recommended version is >=1.6.0. We run the build command on Linux locally and it works well. An alternative option is to use the imgtool script from the upstream MCUBoot repo. To achieve that you can copy the folder ./build_dir/lib/ext/mcuboot-src/scripts/imgtool to bl2/ext/mcuboot/scripts/wrapper/. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Wednesday, January 27, 2021 12:28 AM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Is Musca-A deprecated already? I'm working on some IAR brokenness for the cypress/psoc64 and for comparison I'm attempting to build for my favorite board, the musca_a, but it seems builds fails now. I think it was working last week, but today I'm unable to build with any of the toolchains. I get the following errors frmo all of them. Here's a gcc build: --- [629/629] Generating tfm_s_ns_signed.bin FAILED: bl2/ext/mcuboot/tfm_s_ns_signed.bin cmd.exe /C "cd /D C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_armclang\bl2\ext\mcuboot && C:\Users\thomasto\AppData\Local\Programs\Python\Python39\python.exe C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.2.0 --layout C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/./signing_layout_s_ns.o -k C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin && "C:\Program Files\CMake\bin\cmake.exe" -E copy C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bin" Traceback (most recent call last): File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 126, in <module> wrap() File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 829, in __call__ return self.main(*args, **kwargs) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 782, in main rv = self.invoke(ctx) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 1066, in invoke return ctx.invoke(self.callback, **ctx.params) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 610, in invoke return callback(*args, **kwargs) File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 121, in wrap img.create(key, public_key_format, enckey, dependencies, boot_record) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\imgtool\image.py", line 378, in create for tag, value in custom_tlvs.items(): AttributeError: 'NoneType' object has no attribute 'items' ninja: build stopped: subcommand failed. --- cmake line: cmake -GNinja -S .. -B . -DTFM_PLATFORM=musca_a "-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DMCUBOOT_LOG_LEVEL=DEBUG -DTFM_PSA_API=ON I've tested building for several of the other targets, which seems to work, but I don't have any of these here. Ideas? Thanks, 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>

4 years, 3 months

2
3
0 0

Re: [TF-M] Is Musca-A deprecated already?

by Minos Galanakis

Hi Thomas, I can also confirm that the build works on a system with the linked environment<https://review.trustedfirmware.org/plugins/gitiles/ci/dockerfiles/+/refs/he…> setup. I have tested your command, as well as the two methods listed in the documentation and all appear to be working. Given this opportunity I would like to share that in accordance to the TrustedFirmware.org project maintenance proposal<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, the project should not be removing a platform in without fair notice. In TF-M we try to do so in three steps between releases: * Adding a deprecation warning patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6516> which will notify the users during compilation and runtime. * Marking is as soon to be deprecated in documentation. * Removing the files on or after the marked release. Back to your problem, I would also confirm that there are no environment variables setting a pre-downloaded repository for TF-M tests. Please let us know how it goes. Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Törnblom via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 27 January 2021 08:46 To: Sherry Zhang <Sherry.Zhang2(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Is Musca-A deprecated already? Hi Sherry, Looks like I have version 1.7.0a1. PS C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_iar> imgtool version 1.7.0a1 Cheers, Thomas Den 2021-01-27 kl. 09:22, skrev Sherry Zhang: Hi Thomas, Can you share the version of the imgtool package you used? The recommended version is >=1.6.0. We run the build command on Linux locally and it works well. An alternative option is to use the imgtool script from the upstream MCUBoot repo. To achieve that you can copy the folder ./build_dir/lib/ext/mcuboot-src/scripts/imgtool to bl2/ext/mcuboot/scripts/wrapper/. Regards, Sherry Zhang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org><mailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: Wednesday, January 27, 2021 12:28 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Is Musca-A deprecated already? I'm working on some IAR brokenness for the cypress/psoc64 and for comparison I'm attempting to build for my favorite board, the musca_a, but it seems builds fails now. I think it was working last week, but today I'm unable to build with any of the toolchains. I get the following errors frmo all of them. Here's a gcc build: --- [629/629] Generating tfm_s_ns_signed.bin FAILED: bl2/ext/mcuboot/tfm_s_ns_signed.bin cmd.exe /C "cd /D C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_armclang\bl2\ext\mcuboot && C:\Users\thomasto\AppData\Local\Programs\Python\Python39\python.exe C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.2.0 --layout C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/./signing_layout_s_ns.o -k C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin && "C:\Program Files\CMake\bin\cmake.exe" -E copy C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bin" Traceback (most recent call last): File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 126, in <module> wrap() File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 829, in __call__ return self.main(*args, **kwargs) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 782, in main rv = self.invoke(ctx) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 1066, in invoke return ctx.invoke(self.callback, **ctx.params) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 610, in invoke return callback(*args, **kwargs) File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 121, in wrap img.create(key, public_key_format, enckey, dependencies, boot_record) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\imgtool\image.py", line 378, in create for tag, value in custom_tlvs.items(): AttributeError: 'NoneType' object has no attribute 'items' ninja: build stopped: subcommand failed. --- cmake line: cmake -GNinja -S .. -B . -DTFM_PLATFORM=musca_a "-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DMCUBOOT_LOG_LEVEL=DEBUG -DTFM_PSA_API=ON I've tested building for several of the other targets, which seems to work, but I don't have any of these here. Ideas? Thanks, 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> -- 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>

4 years, 3 months

1
0
0 0

Is Musca-A deprecated already?

by Thomas Törnblom

I'm working on some IAR brokenness for the cypress/psoc64 and for comparison I'm attempting to build for my favorite board, the musca_a, but it seems builds fails now. I think it was working last week, but today I'm unable to build with any of the toolchains. I get the following errors frmo all of them. Here's a gcc build: --- [629/629] Generating tfm_s_ns_signed.bin FAILED: bl2/ext/mcuboot/tfm_s_ns_signed.bin cmd.exe /C "cd /D C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\cmake_build_armclang\bl2\ext\mcuboot && C:\Users\thomasto\AppData\Local\Programs\Python\Python39\python.exe C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/scripts/wrapper/wrapper.py -v 1.2.0 --layout C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/CMakeFiles/signing_layout_s.dir/./signing_layout_s_ns.o -k C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/bl2/ext/mcuboot/root-RSA-3072.pem --public-key-format full --align 1 --pad --pad-header -H 0x400 -s auto -d "(0, 0.0.0+0)" -d "(1, 0.0.0+0)" tfm_s_ns.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin && "C:\Program Files\CMake\bin\cmake.exe" -E copy C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bl2/ext/mcuboot/tfm_s_ns_signed.bin C:/Users/thomasto/Projects/tf-m4/trusted-firmware-m/cmake_build_armclang/bin" Traceback (most recent call last): File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 126, in <module> wrap() File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 829, in __call__ return self.main(*args, **kwargs) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 782, in main rv = self.invoke(ctx) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 1066, in invoke return ctx.invoke(self.callback, **ctx.params) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\click\core.py", line 610, in invoke return callback(*args, **kwargs) File "C:\Users\thomasto\Projects\tf-m4\trusted-firmware-m\bl2\ext\mcuboot\scripts\wrapper\wrapper.py", line 121, in wrap img.create(key, public_key_format, enckey, dependencies, boot_record) File "C:\Users\thomasto\AppData\Local\Programs\Python\Python39\lib\site-packages\imgtool\image.py", line 378, in create for tag, value in custom_tlvs.items(): AttributeError: 'NoneType' object has no attribute 'items' ninja: build stopped: subcommand failed. --- cmake line: cmake -GNinja -S .. -B . -DTFM_PLATFORM=musca_a "-DTFM_TOOLCHAIN_FILE=..\toolchain_GNUARM.cmake" -DTEST_NS=ON -DTEST_S=ON -DCMAKE_BUILD_TYPE=Debug -DMCUBOOT_LOG_LEVEL=DEBUG -DTFM_PSA_API=ON I've tested building for several of the other targets, which seems to work, but I don't have any of these here. Ideas? Thanks, 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>

4 years, 3 months

1
0
0 0

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

by Kevin Peng

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> On Behalf Of Andrew Thoelke via TF-M Sent: Friday, January 15, 2021 1:25 AM To: tf-m(a)lists.trustedfirmware.org; nd <nd(a)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

4 years, 3 months

1
0
0 0

[RFC] Doxygen usage

by Ken Liu

Hi, As mentioned in Tech Forum, call for feedbacks for doxygen usage: - Anyone is checking doxygen documents? - Which API are you checking with doxygen documents? The service APIs, or even some internal static API for SPM? - When you are reading code, will you check the docs or you just open them in editors and then read it? The background is we put many efforts on docs, it costs effort to maintain the doxygen format comments for all sources even the concept is covered in the docs folder, we are trying to find a balance to help mitigate the effort spent on internal logics (such as those static APIs inside SPM fewer people would update). For the interfaces API, doxygen would be always there so user can find them easily. Thanks /Ken

4 years, 3 months

1
0
0 0

Review request on design proposal of adding secure Flash support in TF-M

by Edward Yang

Hi everyone, The design proposal of adding secure Flash support in TF-M has been updated, I would like to ask for a review, any comments and suggestions will be appreciated. Link of the design proposal: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8033 Best Regards, 杨雪松 Edward Yang 旺宏微电子（苏州）有限公司 Macronix Microelectronics(Suzhou) Co., Ltd. 地址：中国苏州工业园区苏虹西路55号 No.55，Su Hong Xi Road，Suzhou Industrail Park，Suzhou 215021 P.R.China TEL: 86-512-62580888 EXT: 3102 FAX: 86-512-62585399 ZIP: 215021 E-mail: edwardyang(a)mxic.com.cn Http: //www.mxic.com.cn ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 3 months

1
0
0 0

Re: [TF-M] Technical Forum call - January 21

by Anton Komlev

Hello, The agenda for the forum: 1. Proposal for changes to the OpenCI job coverage 2. Proposal to reduce Doxygen coverage to the interfaces only 3. Ongoing open issues: * Musca-A platform deprecation * Arm Firmware Framework for M 1.1 Extensions Alpha specification Regards,, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: 20 January 2021 14:18 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Technical Forum call - January 21 Hi Anton, I would like to raise a discussion about doxygen usage. I think it is acceptable to apply doxygen usage in interfaces only if we want to keep alignment with CMSIS code since it applied doxygen result as reference manual; but for other logics, the doxygen is almost not used. Wondered how many users would generate reference manual from doxygen; or they just open an editor then start reading code from sources. Thanks. /Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Karl Zhang via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Wednesday, January 20, 2021 7:54 PM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <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] Technical Forum call - January 21 Hi Anton, I would like to propose some changes to the openCI job coverage, it may take ~20 mins. BR Karl ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: Thursday, January 14, 2021 4:19 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> <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] Technical Forum call - January 21 Hello, The next Technical Forum is planned on Thursday, January 21 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

4 years, 3 months

1
0
0 0

Re: [TF-M] Technical Forum call - January 21

by Ken Liu

Hi Anton, I would like to raise a discussion about doxygen usage. I think it is acceptable to apply doxygen usage in interfaces only if we want to keep alignment with CMSIS code since it applied doxygen result as reference manual; but for other logics, the doxygen is almost not used. Wondered how many users would generate reference manual from doxygen; or they just open an editor then start reading code from sources. Thanks. /Ken ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Karl Zhang via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, January 20, 2021 7:54 PM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>; Anton Komlev <Anton.Komlev(a)arm.com> Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Technical Forum call - January 21 Hi Anton, I would like to propose some changes to the openCI job coverage, it may take ~20 mins. BR Karl ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, January 14, 2021 4:19 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - January 21 Hello, The next Technical Forum is planned on Thursday, January 21 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

4 years, 3 months

1
0
0 0

Re: [TF-M] Technical Forum call - January 21

by Karl Zhang

Hi Anton, I would like to propose some changes to the openCI job coverage, it may take ~20 mins. BR Karl ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Thursday, January 14, 2021 4:19 AM To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - January 21 Hello, The next Technical Forum is planned on Thursday, January 21 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

4 years, 3 months

1
0
0 0

Couple of adjustment patches coming

by Ken Liu

Hi, For implementing coming features and optimization, there would be couples of adjustment patches coming, this is the first one (the number looks good): https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/8000 The idea is to get these patches to come in first so that we can have more time before the next release to fix spotted issues. Please help to review the patches and provide different thinking if you have. Thanks. /Ken

4 years, 3 months

1
0
0 0

Re: [TF-M] [RFC] Static linker scripts for level 1 and 2 isolation

by Ken Liu

Hi, I have merged these patches so they took place now. For lv1 and lv2 users, they don’t need the linker script template any more. The next step is syncing lv3 with lv1/lv2. This change may miss verification on some platforms, please report the build & run issue if you have, thanks. BR /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Thursday, January 14, 2021 9:49 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [RFC] Static linker scripts for level 1 and 2 isolation I think the link needs to be updated into: https://review.trustedfirmware.org/q/topic:%22static_linker_scripts%22+(sta… This would make the components arrangement more simpler than using a templating. But for level 3 we still have to using a templating as now there is no 'foreach' like functionalities supported in the ld/sct/icf. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: Wednesday, January 13, 2021 11:44 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Static linker scripts for level 1 and 2 isolation Hi everyone I'd like to request comments on an upcoming change to the linker scripts. Because of some recent changes to the memory layout for level 1 and level 2 isolation, it's now possible to avoid the generation step via tfm_parse_manifest_lists.py for those linker files. This means that the files are static and have been committed into the source tree (as they used to be). We anticipate this change will make integrating TF-M into non-cmake buildsystems easier, as it will avoid one of the places where files need to be generated at build-time. The reason this is an RFC is that it is a potentially breaking change, but only for integrators _not_ using the cmake buildsystem. Currently the linker uses a large variety of pattern matches to organise the partition symbols, with these patterns being defined in the tfm_manifest_list.yaml. After this change, the linker will only look for two patterns: `*app_rot_partition*` and `*psa_rot_partition*` With the intention that the secure partitions will be compiled into a static library, where the filename is (for example) `libtfm_psa_rot_partition_crypto.a`. The cmake buildsystem will be updated to generate these filenames, but other integrators will need to adjust their compilation steps else the linking will fail. Any comments or concerns would be appreciated. Patches can be found at: https://review.trustedfirmware.org/q/topic:%23static_linker_scripts%22 Raef -- 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

4 years, 3 months

1
0
0 0

Re: [TF-M] Musca-A platform deprecation announcement

by Thomas Törnblom

Hi Anton, The Musca-A is my first choice for testing new things with TF-M, mainly because that’s the simplest Arm board I have access to. What alternative do you recommend? Cheers, Thomas 18 jan. 2021 kl. 18:01 skrev Anton Komlev via TF-M <tf-m(a)lists.trustedfirmware.org>: Hello, I would like to propose the deprecation of Musca-A platform. With whole respect to the first HW platform supported TF-M, it became quite old and difficult to access. The current plan is to remove Musca-A from support and TF-M master code in the next release v1.3.0. Please reply to this mail until Feb 16 (in 4 weeks) having any objection for deprecation. Thanks and Best regards Anton Komlev -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 3 months

2
1
0 0

Musca-A platform deprecation announcement

by Anton Komlev

Hello, I would like to propose the deprecation of Musca-A platform. With whole respect to the first HW platform supported TF-M, it became quite old and difficult to access. The current plan is to remove Musca-A from support and TF-M master code in the next release v1.3.0. Please reply to this mail until Feb 16 (in 4 weeks) having any objection for deprecation. Thanks and Best regards Anton Komlev

4 years, 3 months

1
0
0 0

Review on Firmware Update service in TF-M

by Sherry Zhang

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

4 years, 3 months

1
0
0 0

Arm Firmware Framework for M 1.1 Extensions Alpha specification

by Andrew Thoelke

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, or discuss the proposals here in the TF-M mailing list. Regards, Andrew

4 years, 3 months

1
0
0 0

Re: [TF-M] Technical Forum call - Jan 7

by Kevin Peng

I'd like give a proposal on how to manage the version of tf-m-tests repo in auto-download mode of the build system. Best Regards, Kevin From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Monday, January 4, 2021 5:33 PM To: Anton Komlev <Anton.Komlev(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Technical Forum call - Jan 7 Hi Anton, I'd like to give a brief introduction to TF-M generic threat model. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: Monday, January 4, 2021 5:30 PM To: 'tf-m(a)lists.trustedfirmware.org' <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] Technical Forum call - Jan 7 Hello, The next Technical Forum is planned on Thursday, January 7 at 6:00-07: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

4 years, 3 months

2
3
0 0

Re: [TF-M] [RFC] Static linker scripts for level 1 and 2 isolation

by Ken Liu

I think the link needs to be updated into: https://review.trustedfirmware.org/q/topic:%22static_linker_scripts%22+(sta… This would make the components arrangement more simpler than using a templating. But for level 3 we still have to using a templating as now there is no 'foreach' like functionalities supported in the ld/sct/icf. /Ken -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: Wednesday, January 13, 2021 11:44 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Static linker scripts for level 1 and 2 isolation Hi everyone I'd like to request comments on an upcoming change to the linker scripts. Because of some recent changes to the memory layout for level 1 and level 2 isolation, it's now possible to avoid the generation step via tfm_parse_manifest_lists.py for those linker files. This means that the files are static and have been committed into the source tree (as they used to be). We anticipate this change will make integrating TF-M into non-cmake buildsystems easier, as it will avoid one of the places where files need to be generated at build-time. The reason this is an RFC is that it is a potentially breaking change, but only for integrators _not_ using the cmake buildsystem. Currently the linker uses a large variety of pattern matches to organise the partition symbols, with these patterns being defined in the tfm_manifest_list.yaml. After this change, the linker will only look for two patterns: `*app_rot_partition*` and `*psa_rot_partition*` With the intention that the secure partitions will be compiled into a static library, where the filename is (for example) `libtfm_psa_rot_partition_crypto.a`. The cmake buildsystem will be updated to generate these filenames, but other integrators will need to adjust their compilation steps else the linking will fail. Any comments or concerns would be appreciated. Patches can be found at: https://review.trustedfirmware.org/q/topic:%23static_linker_scripts%22 Raef -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 3 months

1
0
0 0

Technical Forum call - January 21

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, January 21 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

4 years, 3 months

1
0
0 0

[RFC] Static linker scripts for level 1 and 2 isolation

by Raef Coles

Hi everyone I'd like to request comments on an upcoming change to the linker scripts. Because of some recent changes to the memory layout for level 1 and level 2 isolation, it's now possible to avoid the generation step via tfm_parse_manifest_lists.py for those linker files. This means that the files are static and have been committed into the source tree (as they used to be). We anticipate this change will make integrating TF-M into non-cmake buildsystems easier, as it will avoid one of the places where files need to be generated at build-time. The reason this is an RFC is that it is a potentially breaking change, but only for integrators _not_ using the cmake buildsystem. Currently the linker uses a large variety of pattern matches to organise the partition symbols, with these patterns being defined in the tfm_manifest_list.yaml. After this change, the linker will only look for two patterns: `*app_rot_partition*` and `*psa_rot_partition*` With the intention that the secure partitions will be compiled into a static library, where the filename is (for example) `libtfm_psa_rot_partition_crypto.a`. The cmake buildsystem will be updated to generate these filenames, but other integrators will need to adjust their compilation steps else the linking will fail. Any comments or concerns would be appreciated. Patches can be found at: https://review.trustedfirmware.org/q/topic:%23static_linker_scripts%22 Raef

4 years, 3 months

1
0
0 0

[RFC] Variable naming refinement in manifest tool

by Kevin Peng

Hi all, I made a patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7817> to refine the variable naming in manifest tooling, specifically the "manifest.manifest" in templates. I'm changing it to "partition.manifest" which should be more accurate and easy understanding. Broadcasting here for anyone has out-of-tree templates. And any comments are welcome. Best Regards, Kevin

4 years, 3 months

1
0
0 0

Re: [TF-M] TF-M generic threat model

by David Hu

Hi Antonio, Thanks a lot for reviewing the threat model and bringing up this topic. To fully mitigate the threat you mentioned, NSPE shall enforce NS tasks isolation and assign/manage NS identifications. IMHO, It mainly relies on non-secure side implementation. Therefore that threat can be covered in the scope of another threat model against NS side. TF-M is trying to figure out how to assist NSPE to manage and transfer NS identifications. Any suggestion or comment is welcome and helpful! 😊 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, December 30, 2020 7:13 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] TF-M generic threat model Hi Hu, I read the threat model and I have a question regarding a potential threat. I’m not sure it should belong to this generic threat model or it is already included in one of those presented. The scenario is the following: a NS App X uses a RoT Service that store data private to X. Another NS App Y can fool the SPE to impersonate X and retrieve its private data. For example, X save a value in the secure storage and Y retrieves this value. TF-M prevents this using non secure client identification mechanism. This is a classic confused deputy problem. Can this be considered a threat in this model or should it belong to another model/TOE? Best, -- Antonio Ken Iannillo Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 https://akiannillo.github.io/

4 years, 3 months

2
2
0 0

Re: [TF-M] Technical Forum call - Jan 7

by David Hu

Hi Anton, I'd like to give a brief introduction to TF-M generic threat model. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Monday, January 4, 2021 5:30 PM To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - Jan 7 Hello, The next Technical Forum is planned on Thursday, January 7 at 6:00-07: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

4 years, 3 months

1
0
0 0

Technical Forum call - Jan 7

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, January 7 at 6:00-07: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

4 years, 3 months

1
0
0 0

[RFC] Remove unused section 'TFM_UNPRIV_DATA'

by Ken Liu

Hi, The existing section 'TFM_UNPRIV_DATA' now holds nothing - it was designed for holding some data belong to the unprivileged code block, while now the unprivileged code is required as read-only and no place for its read-write data. Remove this section as it is unused; also remove those code objects exists in the unprivileged code section but has read-write data: 'platform_retarget_dev.o' and 'device_definition.o'. This patch changes some sources inside the platforms, so the platform owner please help to check if that matters: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7754 Thanks. /Ken

4 years, 3 months

1
1
0 0

Re: [TF-M] TF-M generic threat model

by Antonio Ken IANNILLO

Hi Hu, I read the threat model and I have a question regarding a potential threat. I’m not sure it should belong to this generic threat model or it is already included in one of those presented. The scenario is the following: a NS App X uses a RoT Service that store data private to X. Another NS App Y can fool the SPE to impersonate X and retrieve its private data. For example, X save a value in the secure storage and Y retrieves this value. TF-M prevents this using non secure client identification mechanism. This is a classic confused deputy problem. Can this be considered a threat in this model or should it belong to another model/TOE? Best, -- Antonio Ken Iannillo Research Scientist – SEDAN group SnT – Interdisciplinary Centre for Security, Reliability and Trust UNIVERSITÉ DU LUXEMBOURG CAMPUS KIRCHBERG 29, avenue John F. Kennedy L-1855 Luxembourg Kirchberg T +352 46 66 44 9660 https://akiannillo.github.io/

4 years, 3 months

1
0
0 0

Re: [TF-M] RFC on changes to install directory structure

by Xinyu Zhang

Hi Raef, Please merge this patch for CI together with your patches. https://review.trustedfirmware.org/c/ci/tf-m-ci-scripts/+/7755 BR, Xinyu -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Raef Coles via TF-M Sent: Tuesday, December 29, 2020 7:56 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] RFC on changes to install directory structure Hi everyone I'd like to request for comment on some changes to the TF-M installed files. Since this is an interface change (though minor), changes to it might cause issues with existing TF-M integrations. The current install directory looks like: install ├── export │ └── tfm └── outputs This doesn't give any useful information about what is contained in each directory. The proposed replacement is: install ├── image_signing ├── interface └── outputs Where the contents of `export/tfm` have been moved into `interface`, which better captures the contents of that directory. `image_signing` is new in the patchset, and contains the scripts, layouts and keys needed to sign an NS image. The final improvement in the patchset is the ability to control the location of the `install` directory via TFM_INSTALL_PATH which could be useful for integrators. Feedback would be appreciated if you feel that these new directory names could be improved, or if this change would cause significant breakage for your TF-M integration. Patchset here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7398/6 Raef -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 3 months

1
0
0 0

RFC on changes to install directory structure

by Raef Coles

Hi everyone I'd like to request for comment on some changes to the TF-M installed files. Since this is an interface change (though minor), changes to it might cause issues with existing TF-M integrations. The current install directory looks like: install ├── export │ └── tfm └── outputs This doesn't give any useful information about what is contained in each directory. The proposed replacement is: install ├── image_signing ├── interface └── outputs Where the contents of `export/tfm` have been moved into `interface`, which better captures the contents of that directory. `image_signing` is new in the patchset, and contains the scripts, layouts and keys needed to sign an NS image. The final improvement in the patchset is the ability to control the location of the `install` directory via TFM_INSTALL_PATH which could be useful for integrators. Feedback would be appreciated if you feel that these new directory names could be improved, or if this change would cause significant breakage for your TF-M integration. Patchset here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7398/6 Raef

4 years, 4 months

1
0
0 0

Changes to TF-M NS interface build

by David Hu

Hi all, Happy holiday! I'd like to let you know that non-secure interface build has been moved from TF-M to tf-m-tests in following patches: TF-M: https://review.trustedfirmware.org/q/topic:%22move-ns-api%22+(status:open%2… Tf-m-tests: https://review.trustedfirmware.org/q/topic:%22add-ns-api%22+(status:open%20… After that change, the .c files under TF-M interface/src are built during non-secure side build. It aligns with the actual process of NS integration with TF-M. Moreover, non-secure specific flags, which control TF-M NS interface, can be configured and managed in non-secure side build, without affecting TF-M secure part. Please modify tf-m-tests app/CMakeLists.txt for future changes to non-secure interface build. Thanks. Best regards, Hu Ziji

4 years, 4 months

1
0
0 0

Re: [TF-M] Discuss how to support secure Flash in TF-M

by David Hu

Hi Poppy, Some rough ideas about secure Flash support in TF-M. IMHO, there can be two options: 1. Based on ITS service Secure Flash acts as the flash driver at the backend of ITS service. The secure Flash driver can invoke Crypto secure service instead of mbedTLS to avoid building two duplicates of mbedTLS library. The cryptographic operation and key management are implemented in secure Flash driver and can be transparent to ITS service while some initialization can be necessary. But it cannot support persistent keys otherwise it will generate a circular dependency between ITS and Crypto services. 1. Based on PS service With PS service, the cryptographic operations can be implemented by PS crypto steps, such as encryption and authentication. Secure Flash driver only covers communication with remote device. We don’t have to worry about the circular dependency with Crypto service. However, there are some limitations of PS service currently: * PS service cannot support multiple asset keys for cryptography. * PS service cannot work alone without ITS service. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Edward Yang via TF-M Sent: Monday, December 21, 2020 1:22 PM To: Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> Cc: Julien Su <juliensu(a)mxic.com.tw<mailto:juliensu@mxic.com.tw>>; tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>; Aaron Zhu <AaronZhu(a)mxic.com.cn<mailto:AaronZhu@mxic.com.cn>>; TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>>; nd <nd(a)arm.com<mailto:nd@arm.com>> Subject: [TF-M] Discuss how to support secure Flash in TF-M Hi Jamie, >As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. The crypto keys you mentioned in your previous reply are the crypto keys used to encrypt the communication channel between host MCU with the secure Flash? Or the secrets such as (public/private)key pairs used in TLS protocol? If the former,I think these keys may be stored in NVM memories such as OTP or internal flash of MCU,and these keys can be loaded and imported as transient keys in RAM with a key handle during such as secure boot, then we can call PSA Crypto service with these key handles, in this case, the dependency from Crypto to secure flash doesn't exist. Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021 苏州工业园区苏虹西路55号 Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn<http://www.mxic.com.cn/> Poppy Wu/CHINA/MXIC 2020/12/16 14:20 To Edward Yang <EdwardYang(a)mxic.com.cn<mailto:EdwardYang@mxic.com.cn>> cc Subject Re: [TF-M] Discuss how to support secure Flash in TF-MLink<Notes://cnmail01/482583DD001E2E02/DABA975B9FB113EB852564B5001283EA/6BDCE39917970ADF4825863F00689523> Hi Jamie, Thank you for your reply. You are right,the secure Flash can be used to store sensitive information like TLS private keys,in this application, during TLS handshake,Crypto service depends on secure Flash driver to get these private keys,so the dependency from Crypto to the secure flash needs to be kept. And you mentioned implementation of crypto functions varies depending on the platform(some platforms have hardware crypto module while the others have to depend on software crypto library), platfrom without HW crypto module could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). As I understand, currently tfm Crypto service also uses Mbed TLS as the backend software crypto library by default. I am wondering if secure Flash driver could call this Mbed TLS library APIs (such as mbedtls_aes_encrypt（）) directly? Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021 苏州工业园区苏虹西路55号 Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn<http://www.mxic.com.cn/> Jamie Fox via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> 2020/12/16 03:02 Please respond to Jamie Fox <Jamie.Fox(a)arm.com<mailto:Jamie.Fox@arm.com>> To Edward Yang <EdwardYang(a)mxic.com.cn<mailto:EdwardYang@mxic.com.cn>> cc nd <nd(a)arm.com<mailto:nd@arm.com>>, "tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>" <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject Re: [TF-M] Discuss how to support secure Flash in TF-M Hi, The trouble with calling the PSA Crypto functions from your secure flash driver is that it will create a circular dependency between the ITS service and the Crypto service. Crypto uses ITS to store its keys, but then the secure flash driver calls the Crypto service again to encrypt the data. These circular dependencies between partitions are forbidden in TF-M. As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. That means the dependency on the Crypto service in the secure flash driver needs to be avoided. I think ideally the best way to do this would be to use hardware crypto functions available in the platform instead of PSA Crypto APIs inside the flash driver, but if no crypto hardware is available then you could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). Hope that helps. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Edward Yang via TF-M Sent: 15 December 2020 10:08 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Discuss how to support secure Flash in TF-M Dear all, I would like to discuss how to add secure Flash support in TF-M. Firstly, I want to describe the motivation of adding secure Flash support in TF-M. Currently ARM TF-M provides protected storage service(PS service for short) to implement security protection on external normal storage, however this type external normal storage is still vulnerable to unauthorized physical modifications/erasing and cloning.Macronix and other Flash memory suppliers have developed secure Flash products to enhance the security in external flash devices. Secure Flash enables mutual authentication between itself and host MCU/SoC and only permits the authorised host to perform access, besides, the communication channel between host MCU/SoC and secure Flash is protected by encryption, authentication, data scrambling, and frame sequencing with monotonic counters as shown below, so the secure Flash provides dependable defense against unauthorised access, man-in-the-middle, replay, sniffing and other security threats. [cid:image001.gif@01D6D91C.DAC89B20] If we port TF-M to a platform which uses secure Flash as external flash,then secure Flash driver should be added to TF-M.However,compared with nomal external flash driver,secure Flash driver needs extra crypto functions(such as calling AES crypto functions to encrypt/decrypt data), if the secure Flash driver is placed in platform folder in TF-M code structure as a backend of ITS service, I don't know whether secure Flash driver is allowed to call Crypto service(such as psa_aead_encrypt(), psa_aead_decrypt() )directly.If not, are there any other solutions to perform crypto operations in secure Flash driver? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn<http://www.mxic.com.cn/> CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================-- TF-M mailing list TF-M(a)lists.trustedfirmware.org<mailto:TF-M@lists.trustedfirmware.org> https://lists.trustedfirmware.org/mailman/listinfo/tf-m CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 4 months

1
0
0 0

Re: [TF-M] TF-M generic threat model

by David Hu

Hi all, I’d like to merge the generic threat model by the end of this week if no further comment. I’m also going to give a brief introduction to TF-M threat modeling in future technical forum. 😊 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Thursday, December 10, 2020 9:37 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M generic threat model Hi all, A generic threat model of TF-M has been uploaded to gerrit. It is a key step in TF-M Threat Modeling. Please help review the threat model document via the link below. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7492 Any question or comment is welcome! Best regards, Hu Ziji

4 years, 4 months

1
0
0 0

Discuss how to support secure Flash in TF-M

by Edward Yang

Hi Jamie, >As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. The crypto keys you mentioned in your previous reply are the crypto keys used to encrypt the communication channel between host MCU with the secure Flash? Or the secrets such as (public/private)key pairs used in TLS protocol? If the former,I think these keys may be stored in NVM memories such as OTP or internal flash of MCU,and these keys can be loaded and imported as transient keys in RAM with a key handle during such as secure boot, then we can call PSA Crypto service with these key handles, in this case, the dependency from Crypto to secure flash doesn't exist. Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021 苏州工业园区苏虹西路55号 Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn Poppy Wu/CHINA/MXIC 2020/12/16 14:20 To Edward Yang <EdwardYang(a)mxic.com.cn> cc Subject Re: [TF-M] Discuss how to support secure Flash in TF-MLink Hi Jamie, Thank you for your reply. You are right,the secure Flash can be used to store sensitive information like TLS private keys,in this application, during TLS handshake,Crypto service depends on secure Flash driver to get these private keys,so the dependency from Crypto to the secure flash needs to be kept. And you mentioned implementation of crypto functions varies depending on the platform(some platforms have hardware crypto module while the others have to depend on software crypto library), platfrom without HW crypto module could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). As I understand, currently tfm Crypto service also uses Mbed TLS as the backend software crypto library by default. I am wondering if secure Flash driver could call this Mbed TLS library APIs (such as mbedtls_aes_encrypt（）) directly? Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021 苏州工业园区苏虹西路55号 Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn Jamie Fox via TF-M <tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2020/12/16 03:02 Please respond to Jamie Fox <Jamie.Fox(a)arm.com> To Edward Yang <EdwardYang(a)mxic.com.cn> cc nd <nd(a)arm.com>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject Re: [TF-M] Discuss how to support secure Flash in TF-M Hi, The trouble with calling the PSA Crypto functions from your secure flash driver is that it will create a circular dependency between the ITS service and the Crypto service. Crypto uses ITS to store its keys, but then the secure flash driver calls the Crypto service again to encrypt the data. These circular dependencies between partitions are forbidden in TF-M. As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. That means the dependency on the Crypto service in the secure flash driver needs to be avoided. I think ideally the best way to do this would be to use hardware crypto functions available in the platform instead of PSA Crypto APIs inside the flash driver, but if no crypto hardware is available then you could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). Hope that helps. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 15 December 2020 10:08 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Discuss how to support secure Flash in TF-M Dear all, I would like to discuss how to add secure Flash support in TF-M. Firstly, I want to describe the motivation of adding secure Flash support in TF-M. Currently ARM TF-M provides protected storage service(PS service for short) to implement security protection on external normal storage, however this type external normal storage is still vulnerable to unauthorized physical modifications/erasing and cloning.Macronix and other Flash memory suppliers have developed secure Flash products to enhance the security in external flash devices. Secure Flash enables mutual authentication between itself and host MCU/SoC and only permits the authorised host to perform access, besides, the communication channel between host MCU/SoC and secure Flash is protected by encryption, authentication, data scrambling, and frame sequencing with monotonic counters as shown below, so the secure Flash provides dependable defense against unauthorised access, man-in-the-middle, replay, sniffing and other security threats. If we port TF-M to a platform which uses secure Flash as external flash,then secure Flash driver should be added to TF-M.However,compared with nomal external flash driver,secure Flash driver needs extra crypto functions(such as calling AES crypto functions to encrypt/decrypt data), if the secure Flash driver is placed in platform folder in TF-M code structure as a backend of ITS service, I don't know whether secure Flash driver is allowed to call Crypto service(such as psa_aead_encrypt(), psa_aead_decrypt() )directly.If not, are there any other solutions to perform crypto operations in secure Flash driver? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================-- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as it attachments from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 4 months

1
0
0 0

Discuss how to support secure Flash in TF-M

by Edward Yang

Hi Jamie, Thank you for your reply. You are right,the secure Flash can be used to store sensitive information like TLS private keys,in this application, during TLS handshake,Crypto service depends on secure Flash driver to get these private keys,so the dependency from Crypto to the secure flash needs to be kept. And you mentioned implementation of crypto functions varies depending on the platform(some platforms have hardware crypto module while the others have to depend on software crypto library), platfrom without HW crypto module could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). As I understand, currently tfm Crypto service also uses Mbed TLS as the backend software crypto library by default. I am wondering if secure Flash driver could call this Mbed TLS library APIs (such as mbedtls_aes_encrypt（）) directly? Best Regards, Poppy Wu 吴偏偏 Macronix Microelectronics (Suzhou) Co.,Ltd 旺宏微电子（苏州）有限公司 No. 55, Su Hong Xi Road ,SIP, Suzhou, PRC, 215021 苏州工业园区苏虹西路55号 Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn Jamie Fox via TF-M <tf-m(a)lists.trustedfirmware.org> Sent by: "TF-M" <tf-m-bounces(a)lists.trustedfirmware.org> 2020/12/16 03:02 Please respond to Jamie Fox <Jamie.Fox(a)arm.com> To Edward Yang <EdwardYang(a)mxic.com.cn> cc nd <nd(a)arm.com>, "tf-m(a)lists.trustedfirmware.org" <tf-m(a)lists.trustedfirmware.org> Subject Re: [TF-M] Discuss how to support secure Flash in TF-M Hi, The trouble with calling the PSA Crypto functions from your secure flash driver is that it will create a circular dependency between the ITS service and the Crypto service. Crypto uses ITS to store its keys, but then the secure flash driver calls the Crypto service again to encrypt the data. These circular dependencies between partitions are forbidden in TF-M. As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. That means the dependency on the Crypto service in the secure flash driver needs to be avoided. I think ideally the best way to do this would be to use hardware crypto functions available in the platform instead of PSA Crypto APIs inside the flash driver, but if no crypto hardware is available then you could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). Hope that helps. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 15 December 2020 10:08 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Discuss how to support secure Flash in TF-M Dear all, I would like to discuss how to add secure Flash support in TF-M. Firstly, I want to describe the motivation of adding secure Flash support in TF-M. Currently ARM TF-M provides protected storage service(PS service for short) to implement security protection on external normal storage, however this type external normal storage is still vulnerable to unauthorized physical modifications/erasing and cloning.Macronix and other Flash memory suppliers have developed secure Flash products to enhance the security in external flash devices. Secure Flash enables mutual authentication between itself and host MCU/SoC and only permits the authorised host to perform access, besides, the communication channel between host MCU/SoC and secure Flash is protected by encryption, authentication, data scrambling, and frame sequencing with monotonic counters as shown below, so the secure Flash provides dependable defense against unauthorised access, man-in-the-middle, replay, sniffing and other security threats. If we port TF-M to a platform which uses secure Flash as external flash,then secure Flash driver should be added to TF-M.However,compared with nomal external flash driver,secure Flash driver needs extra crypto functions(such as calling AES crypto functions to encrypt/decrypt data), if the secure Flash driver is placed in platform folder in TF-M code structure as a backend of ITS service, I don't know whether secure Flash driver is allowed to call Crypto service(such as psa_aead_encrypt(), psa_aead_decrypt() )directly.If not, are there any other solutions to perform crypto operations in secure Flash driver? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================-- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 4 months

2
1
0 0

[CANCELLED] TF-M Technical Forum - December 24

by Anton Komlev

Hello, Probably the next Technical Forum will not be very popular, planned on Thursday, Dec 24 (US friendly time zone). Let's cancel this slot to meet again in January 7. Wish you pleasant holidays and Happy New Year. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

4 years, 4 months

1
0
0 0

Tiny update on the code review guidelines

by Ken Liu

Hi, The purpose of code review guidelines is trying to provide some reference for reviewers. It is still in the evaluation stage. After it gets matured then we can pointer to this document as a required reference. I updated some part of it, the main changes: - The private symbol (static inside a source file) can have a prefix for easier source viewing, a reader would know it is a symbol in the file he/she is viewing which can avoid cross-files 'find reference' operation in the editor. - Clarifies the header file types and the usage: A 'interface' header file is for abstraction, and a typical 'include' header contains exported functionalities for external module usage. Please help to take a look if you have time - as this is one of the upcoming updates, I will treat the review contents out of the changed lines into a new patch if it is possible. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7577 Thanks. /Ken

4 years, 4 months

1
0
0 0

Re: [TF-M] Discuss how to support secure Flash in TF-M

by Jamie Fox

Hi, The trouble with calling the PSA Crypto functions from your secure flash driver is that it will create a circular dependency between the ITS service and the Crypto service. Crypto uses ITS to store its keys, but then the secure flash driver calls the Crypto service again to encrypt the data. These circular dependencies between partitions are forbidden in TF-M. As I understand it, one of the uses of the secure flash is to store crypto keys, so the dependency from Crypto to the secure flash needs to be kept. That means the dependency on the Crypto service in the secure flash driver needs to be avoided. I think ideally the best way to do this would be to use hardware crypto functions available in the platform instead of PSA Crypto APIs inside the flash driver, but if no crypto hardware is available then you could use AES encrypt/decrypt functions from a software crypto library (e.g. Mbed TLS). Hope that helps. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 15 December 2020 10:08 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Discuss how to support secure Flash in TF-M Dear all, I would like to discuss how to add secure Flash support in TF-M. Firstly, I want to describe the motivation of adding secure Flash support in TF-M. Currently ARM TF-M provides protected storage service(PS service for short) to implement security protection on external normal storage, however this type external normal storage is still vulnerable to unauthorized physical modifications/erasing and cloning.Macronix and other Flash memory suppliers have developed secure Flash products to enhance the security in external flash devices. Secure Flash enables mutual authentication between itself and host MCU/SoC and only permits the authorised host to perform access, besides, the communication channel between host MCU/SoC and secure Flash is protected by encryption, authentication, data scrambling, and frame sequencing with monotonic counters as shown below, so the secure Flash provides dependable defense against unauthorised access, man-in-the-middle, replay, sniffing and other security threats. [cid:image001.gif@01D6D313.1B0E4E10] If we port TF-M to a platform which uses secure Flash as external flash,then secure Flash driver should be added to TF-M.However,compared with nomal external flash driver,secure Flash driver needs extra crypto functions(such as calling AES crypto functions to encrypt/decrypt data), if the secure Flash driver is placed in platform folder in TF-M code structure as a backend of ITS service, I don't know whether secure Flash driver is allowed to call Crypto service(such as psa_aead_encrypt(), psa_aead_decrypt() )directly.If not, are there any other solutions to perform crypto operations in secure Flash driver? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn<http://www.mxic.com.cn/> CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 4 months

1
0
0 0

Discuss how to support secure Flash in TF-M

by Edward Yang

Dear all, I would like to discuss how to add secure Flash support in TF-M. Firstly, I want to describe the motivation of adding secure Flash support in TF-M. Currently ARM TF-M provides protected storage service(PS service for short) to implement security protection on external normal storage, however this type external normal storage is still vulnerable to unauthorized physical modifications/erasing and cloning.Macronix and other Flash memory suppliers have developed secure Flash products to enhance the security in external flash devices. Secure Flash enables mutual authentication between itself and host MCU/SoC and only permits the authorised host to perform access, besides, the communication channel between host MCU/SoC and secure Flash is protected by encryption, authentication, data scrambling, and frame sequencing with monotonic counters as shown below, so the secure Flash provides dependable defense against unauthorised access, man-in-the-middle, replay, sniffing and other security threats. If we port TF-M to a platform which uses secure Flash as external flash,then secure Flash driver should be added to TF-M.However,compared with nomal external flash driver,secure Flash driver needs extra crypto functions(such as calling AES crypto functions to encrypt/decrypt data), if the secure Flash driver is placed in platform folder in TF-M code structure as a backend of ITS service, I don't know whether secure Flash driver is allowed to call Crypto service(such as psa_aead_encrypt(), psa_aead_decrypt() )directly.If not, are there any other solutions to perform crypto operations in secure Flash driver? Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd Tel: 86-512-62580888 EXT: 3147 Fax: 86-512-62585399 ZIP: 215021 http://www.mxic.com.cn ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 4 months

1
0
0 0

ITS and PS HALs pushed for review

by Jamie Fox

Hi all, I have pushed for review the new Internal Trusted Storage and Protected Storage HAL designs, as well as an initial implementation for AN521. I will update the change for all other platforms once the design has settled down. It expands the ITS and PS HALs to cover all flash and filesystem configuration parameters required from the platform. The CMSIS Flash Driver is exposed to abstract the flash device itself. ITS is updated to use the new HALs, with its_flash_info_external.c, its_flash_info_internal.c and its_flash.c removed. The ITS filesystem is updated to take a configuration struct as an initialisation parameter, which is filled using values from the HAL. The gerrit reviews are: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/4781 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7598 Kind regards, Jamie

4 years, 4 months

1
0
0 0

Re: [TF-M] [RFC] Moving partition stack into partition BSS/ZI.

by Ken Liu

😉 No response got yet, as it is closing to Xmas, plan to merge them before end of this week (18th Dec) if there is no more voice. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Monday, December 7, 2020 3:22 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [RFC] Moving partition stack into partition BSS/ZI. Hi, We are now allocating partition’s stack inside linker script file, and there are two external patches trying to move these stack definitions into partition’s BSS/ZI: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5374/5 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6508/1 The advantages: - Simplify the linker script/sct templating, stack items can be saved. - Stack as global just uses 8 bytes alignment instead of wider bytes alignment (such as 32 bytes in most of the cases). - Stack is private data, putting private data together is a direct way. And the disadvantages: - Stack memory and global memory may affect each other – actually we don’t apply such protecting mechanism now? Anything I missed? Any feedbacks are welcome. We would collect your feedbacks and update the patches if they are still available after your comments. Other proposals are welcome, too. Thanks. /Ken

4 years, 4 months

1
0
0 0

Proposal to fix the version of tf-m-tests for auto-downloading in build system

by Kevin Peng

Hi all, The build system currently fetches the latest "master" of tf-m-tests repo for building, if auto-download dependencies mode is used (which is the default). This would break the building when: * TF-M and tf-m-tests have dependency changes got merged * A developer is working with a local copy of TF-M that has not been updated to the latest. * The developer does a clean build with auto-downloading * The build system fetch the latest tf-m-tests repo which is not compatible with the local copy of TF-M We've seen this kind of issue reported in mailing list. To solve this problem, the proposal<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7550> of fixing the "TFM_TEST_REPO_VERSION" to a hash or tag is raised. With this change, the build system would download a compatible version always. The version of the test repo is not required to be updated for every commit in the test repo. (Guide line on when to update the version is required and it's still under discussion - welcome for ideas.) Developers want a different version can always override "TFM_TEST_REPO_PATH" to a local copy to build. Best Regards, Kevin

4 years, 4 months

1
0
0 0

Re: [TF-M] Secure Enclave solution in TF-M + New path for Musca-B1 platform

by Mark Horvath

Dear All, The Secure Enclave patches have been merged and caused a minor source structure change. The platform so far named musca_b1 became musca_b1/sse_200, because we added support to the other subsystem on the Musca-B1 board, musca_b1/secure_enclave. So to build onto the old Musca-B1 platform the -DTFM_PLATFORM=musca_b1/sse_200 flag will be needed. All information about the Secure Enclave topic can be found in these rsts: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/desig… https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/refer… https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/e… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: 09 December 2020 10:11 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Secure Enclave solution in TF-M Dear All, The patches for the Secure Enclave topic are planned to be merged soon if no further comments raised. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Mark Horvath via TF-M Sent: 03 December 2020 16:38 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: Re: [TF-M] Secure Enclave solution in TF-M Dear All, I would like to merge the Secure Enclave topic at about middle of next week, feel free to give any feedback. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Mark Horvath via TF-M Sent: 14 September 2020 21:00 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Secure Enclave solution in TF-M Dear All, Following the tech forum presentation (back in 6th August) I uploaded the draft design document for the Secure Enclave topic: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5653 I also updated the first implementation of the proposed solution for the Musca-B1 board with minimal features, marked as WIP: https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Limitations, missing features, notes: * No support for isolation level2 on SSE-200 * Protected Storage is an Application RoT partition, but PS also moved to Secure Enclave * Some regression tests running on secure side of SSE-200 fail as all messages are forwarded with the same client ID to Secure Enclave * All IPC message forwarding is a blocking call * Only one message is put into the mailbox at a time * Musca-B1 related documentation is not complete yet * Generated files are not committed, manifest parser should be run before build. * The BL0 component mentioned in the tech forum presentation is not uploaded, as it is based on the new cmake system, and not so interesting right now * Cmake changes are rudimentary, will be rebased to new cmake system. Any feedback very welcomed! Best regards, Márk Horváth Senior Software Engineer Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com> Arm Hungary Kft., Corvin Offices II, Crystal Tower, Budapest, Futó u. 45. H-1082 Hungary www.arm.com<http://www.arm.com/>

4 years, 4 months

1
0
0 0

TF-M generic threat model

by David Hu

Hi all, A generic threat model of TF-M has been uploaded to gerrit. It is a key step in TF-M Threat Modeling. Please help review the threat model document via the link below. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7492 Any question or comment is welcome! Best regards, Hu Ziji

4 years, 4 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - December 10

by Anton Komlev

Hi All The agenda for the forum: 1. PSA FF-M v1.1 alpha specification overview. Do not miss it! 2. AOB Thanks, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M Sent: 09 December 2020 15:42 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] TF-M Technical Forum call - December 10 Hi all, The proposed version 1.1 extensions to PSA FF-M version 1.0 will be published as an alpha specification in the next few weeks. I would like to update the Technical Forum on the final set of features for v1.1. (Some of these have already been presented earlier this year to the forum) Kind regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Anton Komlev via TF-M Sent: 02 December 2020 15:45 To: 'tf-m(a)lists.trustedfirmware.org' <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 Technical Forum call - December 10 Hello, The next Technical Forum is planned on Thursday, December 10 at 6:00-07: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

4 years, 4 months

1
0
0 0

SW countermeasure against physical attacks in SPE

by Tamas Ban

Hi, PSA Level 3 certification mandates protection against physical attack at a certain extent. MCUboot v1.7.0 release already contains SW countermeasures against fault injection attacks. These can be used at device boot-up time. But fault injection attacks are not targeting only the device boot-up time, instead they could be applied against the runtime firmware. The following design proposal is addressing this threat: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7476 Prototype implementation on AN521 and Musca-B1 target (top of the patch set): https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7475/1 Review and comments are welcome! BR, Tamas Ban

4 years, 4 months

1
0
0 0

Re: [TF-M] TF-M Technical Forum call - December 10

by Andrew Thoelke

Hi all, The proposed version 1.1 extensions to PSA FF-M version 1.0 will be published as an alpha specification in the next few weeks. I would like to update the Technical Forum on the final set of features for v1.1. (Some of these have already been presented earlier this year to the forum) Kind regards, Andrew From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: 02 December 2020 15:45 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M Technical Forum call - December 10 Hello, The next Technical Forum is planned on Thursday, December 10 at 6:00-07: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

4 years, 4 months

1
0
0 0

Re: [TF-M] Secure Enclave solution in TF-M

by Mark Horvath

Dear All, The patches for the Secure Enclave topic are planned to be merged soon if no further comments raised. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: 03 December 2020 16:38 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Secure Enclave solution in TF-M Dear All, I would like to merge the Secure Enclave topic at about middle of next week, feel free to give any feedback. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Mark Horvath via TF-M Sent: 14 September 2020 21:00 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Subject: [TF-M] Secure Enclave solution in TF-M Dear All, Following the tech forum presentation (back in 6th August) I uploaded the draft design document for the Secure Enclave topic: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5653 I also updated the first implementation of the proposed solution for the Musca-B1 board with minimal features, marked as WIP: https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Limitations, missing features, notes: * No support for isolation level2 on SSE-200 * Protected Storage is an Application RoT partition, but PS also moved to Secure Enclave * Some regression tests running on secure side of SSE-200 fail as all messages are forwarded with the same client ID to Secure Enclave * All IPC message forwarding is a blocking call * Only one message is put into the mailbox at a time * Musca-B1 related documentation is not complete yet * Generated files are not committed, manifest parser should be run before build. * The BL0 component mentioned in the tech forum presentation is not uploaded, as it is based on the new cmake system, and not so interesting right now * Cmake changes are rudimentary, will be rebased to new cmake system. Any feedback very welcomed! Best regards, Márk Horváth Senior Software Engineer Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com> Arm Hungary Kft., Corvin Offices II, Crystal Tower, Budapest, Futó u. 45. H-1082 Hungary www.arm.com<http://www.arm.com/>

4 years, 4 months

1
0
0 0

TF-M openCI nightly notification mail list is ready to subscribe

by Karl Zhang

Hi, There is a CI notification mail list enabled, it aims to send the failure info of TF-M nightly job to the subscribers without spam to a big group. If you are interested in the master branch nightly verification status, feel free to add your email to the list. Subscribing: https://lists.trustedfirmware.org/mailman/listinfo/tf-m-ci-notifications The notification only triggers a notification when CI build or test fail occur from the nightly job. Thanks Karl

4 years, 4 months

1
0
0 0

IAR, problems building with 8.50.9

by Thomas Törnblom

IAR released a new service pack late last week, version 8.50.9. This service pack includes a new compiler version, which although thoroughly tested, apparently introduced a new intricate bug, which causes at least the musca_a mcuboot to fail. The issue has been identified and fixed, and the next release should have this fix. I have no date for when this will be released or in what form. So for the time being, please do not upgrade above version 8.50.7. Thanks, 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>

4 years, 4 months

1
0
0 0

[RFC] Moving partition stack into partition BSS/ZI.

by Ken Liu

Hi, We are now allocating partition's stack inside linker script file, and there are two external patches trying to move these stack definitions into partition's BSS/ZI: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5374/5 https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6508/1 The advantages: - Simplify the linker script/sct templating, stack items can be saved. - Stack as global just uses 8 bytes alignment instead of wider bytes alignment (such as 32 bytes in most of the cases). - Stack is private data, putting private data together is a direct way. And the disadvantages: - Stack memory and global memory may affect each other - actually we don't apply such protecting mechanism now? Anything I missed? Any feedbacks are welcome. We would collect your feedbacks and update the patches if they are still available after your comments. Other proposals are welcome, too. Thanks. /Ken

4 years, 4 months

1
0
0 0

[RFC] Build: Move UART symbols to SPRTL

by Kevin Peng

Hi Platform owners, explicitly ST, Nordic and NXP owners. Could you confirm that this patch<https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/6678> wouldn't break your platforms. The patch changes the build system to put the UART drivers to the SPRTL. It is important to improve the isolation implementations. For more details, please see the patch. We will wait for one more week and merge it as is if no feedbacks. Any feedbacks from others are welcome always. Best Regards, Kevin

4 years, 4 months

1
0
0 0

Re: [TF-M] Secure Enclave solution in TF-M

by Mark Horvath

Dear All, I would like to merge the Secure Enclave topic at about middle of next week, feel free to give any feedback. https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Best regards, Mark From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mark Horvath via TF-M Sent: 14 September 2020 21:00 To: 'tf-m(a)lists.trustedfirmware.org' <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Secure Enclave solution in TF-M Dear All, Following the tech forum presentation (back in 6th August) I uploaded the draft design document for the Secure Enclave topic: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/5653 I also updated the first implementation of the proposed solution for the Musca-B1 board with minimal features, marked as WIP: https://review.trustedfirmware.org/q/topic:%22Secure+Enclave%22+(status:ope… Limitations, missing features, notes: * No support for isolation level2 on SSE-200 * Protected Storage is an Application RoT partition, but PS also moved to Secure Enclave * Some regression tests running on secure side of SSE-200 fail as all messages are forwarded with the same client ID to Secure Enclave * All IPC message forwarding is a blocking call * Only one message is put into the mailbox at a time * Musca-B1 related documentation is not complete yet * Generated files are not committed, manifest parser should be run before build. * The BL0 component mentioned in the tech forum presentation is not uploaded, as it is based on the new cmake system, and not so interesting right now * Cmake changes are rudimentary, will be rebased to new cmake system. Any feedback very welcomed! Best regards, Márk Horváth Senior Software Engineer Mark.Horvath(a)arm.com<mailto:Mark.Horvath@arm.com> Arm Hungary Kft., Corvin Offices II, Crystal Tower, Budapest, Futó u. 45. H-1082 Hungary www.arm.com<http://www.arm.com/>

4 years, 4 months

1
0
0 0

Review request of TF-M dual-cpu mailbox enhancement

by David Hu

Hi all, Could you please help the patches to enhance TF-M dual-cpu mailbox, as discussed in last Technical Forum? Improvements to make NS RTOS port easier: https://review.trustedfirmware.org/q/topic:%22mailbox-enhance%22+(status:op… A new working model to support NS RTOS application isolation better: https://review.trustedfirmware.org/q/topic:%22mailbox-dedicated-thread%22+(… Any comment is welcome! Please see the slides for the basic ideas of the enhancements mentioned above. Slides link: https://www.trustedfirmware.org/docs/TF-M_Dual-cpu_NSPE_mailbox_enhancement… Best regards, Hu Ziji

4 years, 4 months

1
0
0 0

Re: [TF-M] Review request for adding External Trusted Secure Storage service in TF-M

by Jamie Fox

Hi, Thank you for the proposal, I have commented in the Gerrit review. Kind regards, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Edward Yang via TF-M Sent: 02 December 2020 14:28 To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Review request for adding External Trusted Secure Storage service in TF-M Hi everyone, Please help review the following design proposal of adding External Trusted Secure Storage service in TF-M,any comments and suggestions will be appreciated. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7295 Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn<http://www.mxic.com.cn/> ======================================================== CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 4 months

1
0
0 0

TF-M Technical Forum call - December 10

by Anton Komlev

Hello, The next Technical Forum is planned on Thursday, December 10 at 6:00-07: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

4 years, 4 months

1
0
0 0

Re: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?)

by Rønningstad, Øyvind

I've created a proof of concept for allowing out-of-tree platforms here: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7301 It was simpler than I had thought :) Øyvind From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Ken Liu via TF-M Sent: Thursday, November 26, 2020 07:57 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?) Hi, In the ideal case with HAL API, the platform itself can decide which variant's layout to be applied, selected by build system switches or just some header files. Because SPM could get what it needed by HAL API run-time. It can be mostly done inside the platform folder if one platform has the variants management already. Others please give inputs as this is a very useful topic, we can list down the problem we met during integration first. BR /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Rønningstad, Øyvind via TF-M Sent: Thursday, November 26, 2020 3:47 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Cc: Rasmussen, Torsten <Torsten.Rasmussen(a)nordicsemi.no<mailto:Torsten.Rasmussen@nordicsemi.no>> Subject: [TF-M] Externally override flash layout and pin configurations (out-of-tree platforms?) Hi all In our work integrating TFM into Zephyr and the nRF Connect SDK, it's apparent that the integration would be a lot smoother if we could specify TFM's flash layout externally. Looking into it a bit, I came up with a draft proposal here: https://github.com/zephyrproject-rtos/trusted-firmware-m/pull/18/files<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…> We could just modify our own platforms to this and be happy, but I'm wondering if there would be interest in standardizing something. Now, a related problem is: How can we make it easier to add multiple boards based on a single chip. For the Nordic platforms we've already separated the chip-specific code (nRF9160/nRF5340) from the board specific code (DK/PDK), and for the boards, it really boils down to pin configurations. We could allow to specify pins via Cmake instead, to easily allow users to support their production PCBs. But (this was brought up in the above PR) we can also solve both problems by adding support for out-of-tree platforms. For example, allow TFM to be built like so: cmake -DTFM_PLATFORM=../../../../my_custom_board ... This would probably be less work that designing a new interface for overriding flash layouts and pin configurations. What are your thoughts? BR, Øyvind Rønningstad

4 years, 4 months

1
0
0 0

Review request for adding External Trusted Secure Storage service in TF-M

by Edward Yang

Hi everyone, Please help review the following design proposal of adding External Trusted Secure Storage service in TF-M,any comments and suggestions will be appreciated. https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/7295 Best Regards, Poppy Wu Macronix Microelectronics (Suzhou) Co.,Ltd http://www.mxic.com.cn ======================================================== ============================================================================ CONFIDENTIALITY NOTE: This e-mail and any attachments may contain confidential information and/or personal data, which is protected by applicable laws. Please be reminded that duplication, disclosure, distribution, or use of this e-mail (and/or its attachments) or any part thereof is prohibited. If you receive this e-mail in error, please notify us immediately and delete this mail as well as its attachment(s) from your system. In addition, please be informed that collection, processing, and/or use of personal data is prohibited unless expressly permitted by personal data protection laws. Thank you for your attention and cooperation. Macronix International Co., Ltd. =====================================================================

4 years, 4 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-M