- TF-M - lists.trustedfirmware.org

Re: [TF-M] Technical Forum call - April 15

by Feder Liang

Hi, Anton I would like to introduce the topic about "FP support in TF-M". It may take about 60 mins. Best Regards Feder From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Wednesday, April 7, 2021 9:27 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] Technical Forum call - April 15 Hi, The next Technical Forum is planned on Thursday, April 15, 15:00-16:00 UTC (US time zone). Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 2 months

2
1
0 0

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

by Kevin Peng

Hi Andrew, [Sorry for the long delay of resuming this discussion.] I think psa_irq_is_enabled() could be removed. As the peripherals are exclusively owned by Partitions, Partitions should be able to manage the status of the IRQs by themselves. And the psa_irq_disable() could still return the previous status. It (and the psa_irq_enable() as well) should be atomic anyway because the caller would consider the IRQ is disabled or enabled by calling the corresponding API. The APIs must ensure the validness, to do that disabling interrupts entirely might be inevitable. In TF-M, this is done by calling SVC in the APIs to tell SPM to manipulate the interrupt controller. And SVC has higher priority than all interrupts. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M Sent: Monday, February 22, 2021 11:03 PM To: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: Re: [TF-M] Arm Firmware Framework for M 1.1 Extensions Alpha specification 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 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

5 years, 2 months

2
1
0 0

Re: [TF-M] Timeframe on release/approval

by Tamas Ban

Hi, TF-M release cadence is 4 month. In theory 1.4 release is around July. Tamas From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Mccrae via TF-M Sent: 2021. április 14., szerda 8:10 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Timeframe on release/approval Hi Minos/David/Shebu, Many thanks for the details. Is there a timeframe in mind for the next major release of TF-M i.e. version 1.4? Thanks, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Shebu Varghese Kuriakose via TF-M Sent: 13 April 2021 17:57 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] Timeframe on release/approval Hi Jamie, My understanding is that Zephyr integrates release tags of TF-M. TF-M v1.2 was integrated and I assume v1.3 will be done sometime soon. Regards, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of David Hu via TF-M Sent: Tuesday, April 13, 2021 3:14 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] Timeframe on release/approval Hi Jaime, Anton and I have reviewed your patch. Please check our comments on the patch. I believe other reviewers will provide their input as well soon. Although it is difficult to guarantee the timeframe in TF-M as in other open-source project, it will speed up the review process if reviewers’ comments can be addressed in time. 😊 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Minos Galanakis via TF-M Sent: Tuesday, April 13, 2021 12:09 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] Timeframe on release/approval Hi Jamie, Thank you very much for your interest in supporting for TF-M in your platform. Since you are contributing a new platform, I would recommend that you read the Trusted Firmware maintenance process<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, for further details on the process. To answer your questions about the timeframe, that really depends on various factors, such as how busy the maintainers of this code are, weather there is a release pending which would follow a code freeze, and how complicated the changes are. I don't believe it is easy to estimate a figure. Regards, Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Jamie Mccrae via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 12 April 2021 09:40 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>> Subject: [TF-M] Timeframe on release/approval Hi, I submitted a patch to add our board to the Trusted Firmware-M repository under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 and was wondering on timeframes for receiving comments or having the pull request accepted? We want to have our board added to Zephyr RTOS and for that, we need the board in TF-M and pulled into the Zephyr version of this repository (I’m not sure if they can pull any version of the code or if they only pull full release versions e.g. 1.3.0), are there any comments on this and does anyone have any idea of a rough estimate the time required from now to get the base files into the zephyr version of the repository so we can submit our boards file? Thanks, Jamie THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.

5 years, 2 months

1
0
0 0

Re: [TF-M] Timeframe on release/approval

by Jamie Mccrae

Hi Minos/David/Shebu, Many thanks for the details. Is there a timeframe in mind for the next major release of TF-M i.e. version 1.4? Thanks, Jamie From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Shebu Varghese Kuriakose via TF-M Sent: 13 April 2021 17:57 To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Timeframe on release/approval Hi Jamie, My understanding is that Zephyr integrates release tags of TF-M. TF-M v1.2 was integrated and I assume v1.3 will be done sometime soon. Regards, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, April 13, 2021 3:14 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Timeframe on release/approval Hi Jaime, Anton and I have reviewed your patch. Please check our comments on the patch. I believe other reviewers will provide their input as well soon. Although it is difficult to guarantee the timeframe in TF-M as in other open-source project, it will speed up the review process if reviewers’ comments can be addressed in time. 😊 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Minos Galanakis via TF-M Sent: Tuesday, April 13, 2021 12:09 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] Timeframe on release/approval Hi Jamie, Thank you very much for your interest in supporting for TF-M in your platform. Since you are contributing a new platform, I would recommend that you read the Trusted Firmware maintenance process<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, for further details on the process. To answer your questions about the timeframe, that really depends on various factors, such as how busy the maintainers of this code are, weather there is a release pending which would follow a code freeze, and how complicated the changes are. I don't believe it is easy to estimate a figure. Regards, Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Jamie Mccrae via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 12 April 2021 09:40 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>> Subject: [TF-M] Timeframe on release/approval Hi, I submitted a patch to add our board to the Trusted Firmware-M repository under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 and was wondering on timeframes for receiving comments or having the pull request accepted? We want to have our board added to Zephyr RTOS and for that, we need the board in TF-M and pulled into the Zephyr version of this repository (I’m not sure if they can pull any version of the code or if they only pull full release versions e.g. 1.3.0), are there any comments on this and does anyone have any idea of a rough estimate the time required from now to get the base files into the zephyr version of the repository so we can submit our boards file? Thanks, Jamie THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.

5 years, 2 months

1
0
0 0

Re: [TF-M] Timeframe on release/approval

by Shebu Varghese Kuriakose

Hi Jamie, My understanding is that Zephyr integrates release tags of TF-M. TF-M v1.2 was integrated and I assume v1.3 will be done sometime soon. Regards, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Tuesday, April 13, 2021 3:14 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Timeframe on release/approval Hi Jaime, Anton and I have reviewed your patch. Please check our comments on the patch. I believe other reviewers will provide their input as well soon. Although it is difficult to guarantee the timeframe in TF-M as in other open-source project, it will speed up the review process if reviewers’ comments can be addressed in time. 😊 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Minos Galanakis via TF-M Sent: Tuesday, April 13, 2021 12:09 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] Timeframe on release/approval Hi Jamie, Thank you very much for your interest in supporting for TF-M in your platform. Since you are contributing a new platform, I would recommend that you read the Trusted Firmware maintenance process<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, for further details on the process. To answer your questions about the timeframe, that really depends on various factors, such as how busy the maintainers of this code are, weather there is a release pending which would follow a code freeze, and how complicated the changes are. I don't believe it is easy to estimate a figure. Regards, Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Jamie Mccrae via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 12 April 2021 09:40 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>> Subject: [TF-M] Timeframe on release/approval Hi, I submitted a patch to add our board to the Trusted Firmware-M repository under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 and was wondering on timeframes for receiving comments or having the pull request accepted? We want to have our board added to Zephyr RTOS and for that, we need the board in TF-M and pulled into the Zephyr version of this repository (I’m not sure if they can pull any version of the code or if they only pull full release versions e.g. 1.3.0), are there any comments on this and does anyone have any idea of a rough estimate the time required from now to get the base files into the zephyr version of the repository so we can submit our boards file? Thanks, Jamie THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.

5 years, 2 months

1
0
0 0

Re: [TF-M] TF-M at Linaro Connect 2021

by Shebu Varghese Kuriakose

The video links to the TF-M presentations @ Linaro Virtual Connect 2021 can be found here - https://developer.trustedfirmware.org/w/tf_m/tf-m_videos/linaro_virtual_con… Thanks, Shebu From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, March 18, 2021 3:58 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] TF-M at Linaro Connect 2021 Hello, This is the list of TF-M related sessions on Linaro Virtual Connect 2021 https://connect.linaro.org/schedule/ * 23/3 @ 17:15 Introducing the Trusted Services project - Julian Hall * 23/3 @ 18:30 Physical Attack Mitigation - Tamas Ban, Raef Coles * 24/3 @ 9:45 Firmware update service in TF-M - Sherry Zhang * 24/3 @ 10:45 Firmware Framework - M 1.1 feature update in TF-M - Ken Liu * 25/3 @ 12:45 X.509 Certificate Management with Zephyr/TF-M - David Vincze * 25/3 @ 13:15 Essential ARM Cortex-M Debugging with GDB - Kevin Townsend Cheers, Anton

5 years, 2 months

1
0
0 0

Re: [TF-M] Timeframe on release/approval

by David Hu

Hi Jaime, Anton and I have reviewed your patch. Please check our comments on the patch. I believe other reviewers will provide their input as well soon. Although it is difficult to guarantee the timeframe in TF-M as in other open-source project, it will speed up the review process if reviewers’ comments can be addressed in time. 😊 Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Minos Galanakis via TF-M Sent: Tuesday, April 13, 2021 12:09 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Timeframe on release/approval Hi Jamie, Thank you very much for your interest in supporting for TF-M in your platform. Since you are contributing a new platform, I would recommend that you read the Trusted Firmware maintenance process<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, for further details on the process. To answer your questions about the timeframe, that really depends on various factors, such as how busy the maintainers of this code are, weather there is a release pending which would follow a code freeze, and how complicated the changes are. I don't believe it is easy to estimate a figure. Regards, Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> on behalf of Jamie Mccrae via TF-M <tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org>> Sent: 12 April 2021 09:40 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>> Subject: [TF-M] Timeframe on release/approval Hi, I submitted a patch to add our board to the Trusted Firmware-M repository under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 and was wondering on timeframes for receiving comments or having the pull request accepted? We want to have our board added to Zephyr RTOS and for that, we need the board in TF-M and pulled into the Zephyr version of this repository (I’m not sure if they can pull any version of the code or if they only pull full release versions e.g. 1.3.0), are there any comments on this and does anyone have any idea of a rough estimate the time required from now to get the base files into the zephyr version of the repository so we can submit our boards file? Thanks, Jamie THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.

5 years, 2 months

1
0
0 0

Re: [TF-M] Timeframe on release/approval

by Minos Galanakis

Hi Jamie, Thank you very much for your interest in supporting for TF-M in your platform. Since you are contributing a new platform, I would recommend that you read the Trusted Firmware maintenance process<https://developer.trustedfirmware.org/w/collaboration/project-maintenance-p…>, for further details on the process. To answer your questions about the timeframe, that really depends on various factors, such as how busy the maintainers of this code are, weather there is a release pending which would follow a code freeze, and how complicated the changes are. I don't believe it is easy to estimate a figure. Regards, Minos ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Jamie Mccrae via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: 12 April 2021 09:40 To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: [TF-M] Timeframe on release/approval Hi, I submitted a patch to add our board to the Trusted Firmware-M repository under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 and was wondering on timeframes for receiving comments or having the pull request accepted? We want to have our board added to Zephyr RTOS and for that, we need the board in TF-M and pulled into the Zephyr version of this repository (I’m not sure if they can pull any version of the code or if they only pull full release versions e.g. 1.3.0), are there any comments on this and does anyone have any idea of a rough estimate the time required from now to get the base files into the zephyr version of the repository so we can submit our boards file? Thanks, Jamie THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.

5 years, 2 months

1
0
0 0

Timeframe on release/approval

by Jamie Mccrae

Hi, I submitted a patch to add our board to the Trusted Firmware-M repository under https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9508 and was wondering on timeframes for receiving comments or having the pull request accepted? We want to have our board added to Zephyr RTOS and for that, we need the board in TF-M and pulled into the Zephyr version of this repository (I'm not sure if they can pull any version of the code or if they only pull full release versions e.g. 1.3.0), are there any comments on this and does anyone have any idea of a rough estimate the time required from now to get the base files into the zephyr version of the repository so we can submit our boards file? Thanks, Jamie THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.

5 years, 2 months

1
0
0 0

TF-M v1.3.0 release

by Anton Komlev

Hello, TF-M project released version v1.3.0, tagged as TF-Mv1.3.0. Please take a look into the release notes for the new features and changes: https://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/docs/refer… The major features: * Support stateless RoT Service defined in FF-M 1.1 * Support Second-Level Interrupt Handling (SLIH) defined in FF-M 1.1 * Add Firmware Update (FWU) secure service, following Platform Security Architecture Firmware Update API * Migrate to Mbed TLS v2.25.0 * Update MCUboot version to v1.7.2 * Add a TF-M generic threat model * Implement Fault Injection Handling library to mitigate physical attacks * Add Profile Large * Enable code sharing between boot loader and TF-M * Support Armv8.1-M Privileged Execute Never (PXN) attribute and Thread reentrancy disabled (TRD) feature * New platforms added * Add a TF-M security landing page * Enhance dual-cpu non-secure mailbox reference implementation This is the first release performed in the OpenCI infrastructure with no single issue encountered. Thanks to everyone who directly and indirectly contributed to this milestone. Anton Komlev TF-M technical lead Arm Ltd.

5 years, 2 months

1
0
0 0

Technical Forum call - April 15

by Anton Komlev

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

5 years, 2 months

1
0
0 0

Re: [TF-M] Issues with alignment and buffer locations

by Ken Liu

Hi Jamie, Thanks for your reply. Looks like it is mostly flash related. I have created one task for tracking this: https://developer.trustedfirmware.org/T918 We need some time to analyze this, so the response may be not short and we would keep updating. Feel free to provide your done solutions on the task. Thanks. /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Mccrae via TF-M Sent: Thursday, April 1, 2021 4:59 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] Issues with alignment and buffer locations Hi Ken, > Could help to provide the details so that we can see what the problem is? Looks like you mentioned two problems here, one for the un-aligned memory accessing and another is the FLASH read/write. Sure. This is being based on the nRF5340 (Cortex-M33) chipset, it uses image swapping rather than overwriting, the primary image is located in the on-chip flash and the secondary slot is located in QSPI flash, the scratch slot is also located in QSPI flash, this is the trailing part of the log when the issue with trying to write to QSPI from a non-RAM buffer occurs (GCC build): [ERR] Qerase 0xfe000 [ERR] Qerase 0xff000 [ERR] read area=3, off=0x9fff0, len=0x10 [ERR] Qread 0x9fff0 10 to 0x20005ad8 [ERR] read area=3, off=0x9ffd8, len=0x1 [ERR] Qread 0x9ffd8 1 to 0x20005ad7 [ERR] read area=3, off=0x9ffe0, len=0x1 [ERR] Qread 0x9ffe0 1 to 0x20005b22 [ERR] read area=3, off=0x9ffe8, len=0x1 [ERR] Qread 0x9ffe8 1 to 0x20005b23 [ERR] write area=5, off=0x1ffd8, len=0x4 [ERR] Qwrite 0xfffd8 4 from 0x20005ae0 [ERR] write area=5, off=0x1ffd0, len=0x4 [ERR] Qwrite 0xfffd0 4 from 0x20005ae0 [ERR] write area=5, off=0x1fff0, len=0x10 [ERR] Qwrite 0xffff0 10 from 0xcfdc [ERR] QSPI write failed -400 assertion "rc == 0" failed: file "lib/ext/mcuboot-src/boot/bootutil/src/swap_misc.c", line 125, function: swap_status_init The final write fails because it is attempting to write to QSPI from a non-RAM address, 0xcfdc is an address in the internal flash. Unless this is possibly an issue with the buffer address being overwritten somehow? > For the memory alignment, to ensure the isolation setting all sections should be 32-bytes aligned; and the stack-alignment is 8 bytes. Other contents are set as default, the toolchain should have handled them correctly. This is the error in the trailing part of the log I am getting with it reading 1 byte at a time to an invalid buffer: [ERR] read area=1, off=0, len=0x20 [ERR] Fread 0x10000 0x20 to 0x20002530 [ERR] read area=3, off=0, len=0x20 [ERR] Qread 0x0 0x20 to 0x2000255c [ERR] read area=1, off=0x9fff0, len=0x10 [ERR] Fread 0xafff0 10 to 0x20005b60 [ERR] read area=1, off=0x9ffd8, len=0x1 [ERR] Fread 0xaffd8 1 to 0x20005b5f [ERR] read area=1, off=0x9ffe0, len=0x1 [ERR] Fread 0xaffe0 1 to 0x20005baa [ERR] read area=1, off=0x9ffe8, len=0x1 [ERR] Fread 0xaffe8 1 to 0x20005bab [ERR] read area=5, off=0x1fff0, len=0x10 [ERR] Qread 0xffff0 10 to 0x20005b60 [ERR] read area=5, off=0x1ffd8, len=0x1 [ERR] Qread 0xfffd8 1 to 0x20005b5f [ERR] Qread QSPI failed assertion "rc == 0" failed: file "lib/ext/mcuboot-src/boot/bootutil/src/swap_scratch.c", line 384, function: swap_status_source The 2 issues are QSPI reads must be multiples of 4 bytes, it cannot read just 1 byte, and secondly the 0x20005b5f buffer is not 4-byte aligned so it cannot be used to store the data anyway. The same GCC linker .ld files are being used as are currently in the TF-M repository for the nRF5340-DK which is 4-byte aligned for data and bss and 8-byte aligned for heap. Qread/Qwrite = QSPI, Fread/Write = internal flash, area 5 is the scratch partition. This is TF-M built with separate secure and non-secure image slots. > Please provide the details, thank you! > > /Ken > > From: TF-M <tf-m-bounces at lists.trustedfirmware.org> On Behalf Of Jamie Mccrae via TF-M > Sent: Monday, March 29, 2021 10:19 PM > To: tf-m at lists.trustedfirmware.org > Subject: [TF-M] Issues with alignment and buffer locations > > Hi, > There seems to be a large oversight in the TF-M codeline relating to buffer alignment and locations of buffers, in terms of buffer alignment, some ARM-based silicon has restrictions on buffer alignment, generally 4-byte boundaries, this means that if a non-4 byte boundary address, buffer or data size is provided, the operation cannot be completed. Another issue is that some ARM-based silicon has restrictions on where data can be located, e.g. in RAM only for writing and not from other address spaces. > I am currently trying to get TF-M working on a Nordic nRF53-based designed and have encountered these issues many times, and can see no way to set an alignment, data size or address space limitation in the whole code line which I find to be quite displeasing given that both the silicon and software are ARM-based, I would expect the software you give for silicon based on your reference designs to actually work with it out of the box rather than need lots of work to have these limitations supported. On Nordic silicon, data can only be written and read from RAM e.g. you cannot write to flash from a flash offset, and writes must be 4-byte aligned and 4-byte sized (the QSPI functionality is being used here). > > So I am emailing here to ask: what is the suggestion for dealing with this? Why does the baseline project not (from what I can see) have any sort of support for this? > Thanks, > Jamie THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.

5 years, 3 months

1
0
0 0

Updated invitation: TF-M Tech forum @ Every 4 weeks from 10am to 11am on Thursday (CDT) (tf-m@lists.trustedfirmware.org)

by Don Harbin

This event has been changed. Title: TF-M Tech forum This is an open forum for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC.Feel free to forward it to colleagues.Details of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/==… Info====Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: TF-M Tech forum - US Time Zone FriendlyTime: Oct 29, 2020 03:00 PM Greenwich Mean Time        Every 4 weeks on Thu, until Mar 18, 2021, 6 occurrence(s)        Oct 29, 2020 03:00 PM        Nov 26, 2020 03:00 PM        Dec 24, 2020 03:00 PM        Jan 21, 2021 03:00 PM        Feb 18, 2021 03:00 PM        Mar 18, 2021 03:00 PMPlease download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJEocOmvpz4tHtYu0Wvn2fOsG91u0kv_ECPd/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz09Meeting ID: 955 7079 5742Passcode: 177658One tap mobile+12532158782,,95570795742# US (Tacoma)+13462487799,,95570795742# US (Houston)Dial by your location        +1 253 215 8782 US (Tacoma)        +1 346 248 7799 US (Houston)        +1 669 900 9128 US (San Jose)        +1 301 715 8592 US (Germantown)        +1 312 626 6799 US (Chicago)        +1 646 558 8656 US (New York)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 955 7079 5742Find your local number: https://linaro-org.zoom.us/u/abx3I7IoRq When: Every 4 weeks from 10am to 11am on Thursday Central Time - Chicago (changed) Where: https://linaro-org.zoom.us/j/95570795742?pwd=N21YWHJpUjZyS3Fzd0tkOG9hanpidz… Calendar: tf-m(a)lists.trustedfirmware.org Who: * Don Harbin - creator * tf-m(a)lists.trustedfirmware.org * anton.komlev(a)arm.com * abdelmalek.omar1(a)gmail.com * kevin.townsend(a)linaro.org * seth(a)nxmlabs.com Event details: https://calendar.google.com/calendar/event?action=VIEW&eid=djczYWZqa3ZmMW5n… Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this courtesy email at the account tf-m(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://calendar.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

5 years, 3 months

1
0
0 0

Issues with alignment and buffer locations

by Jamie Mccrae

Hi, There seems to be a large oversight in the TF-M codeline relating to buffer alignment and locations of buffers, in terms of buffer alignment, some ARM-based silicon has restrictions on buffer alignment, generally 4-byte boundaries, this means that if a non-4 byte boundary address, buffer or data size is provided, the operation cannot be completed. Another issue is that some ARM-based silicon has restrictions on where data can be located, e.g. in RAM only for writing and not from other address spaces. I am currently trying to get TF-M working on a Nordic nRF53-based designed and have encountered these issues many times, and can see no way to set an alignment, data size or address space limitation in the whole code line which I find to be quite displeasing given that both the silicon and software are ARM-based, I would expect the software you give for silicon based on your reference designs to actually work with it out of the box rather than need lots of work to have these limitations supported. On Nordic silicon, data can only be written and read from RAM e.g. you cannot write to flash from a flash offset, and writes must be 4-byte aligned and 4-byte sized (the QSPI functionality is being used here). So I am emailing here to ask: what is the suggestion for dealing with this? Why does the baseline project not (from what I can see) have any sort of support for this? Thanks, Jamie THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.

5 years, 3 months

1
1
0 0

Re: [TF-M] Technical Forum call - April 1 (not a joke :)

by Anton Komlev

Hi, the agenda for the forum tomorrow : 1. News and update by Anton Komlev 2. Open discussion on TF-M documentation structure by David Wang 3. Stateless handle and service in TF-M by Mingyang Sun 4. AOB Regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Wang via TF-M Sent: Tuesday, March 30, 2021 3:20 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] Technical Forum call - April 1 (not a joke :) Hi Anton, If we still have slot, I'd like to share some thoughts and have a discussion for the TF-M documentation structure. It should be less than 20 mins. Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Mingyang Sun via TF-M Sent: Monday, March 29, 2021 11:15 AM To: Anton Komlev <Anton.Komlev(a)arm.com<mailto:Anton.Komlev@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] Technical Forum call - April 1 (not a joke :) Hi Anton, I'd like give a short session on "stateless handle and service in TF-M", about 20min. Regards, Mingyang 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: Friday, March 26, 2021 6:57 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] Technical Forum call - April 1 (not a joke :) Hi, The next Technical Forum is planned on Thursday, April 1 , 07:00-08:00 UTC (Asia time zone). Please mine the gap of the time change in Europe! Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 3 months

1
0
0 0

TF-M v1.3.0 Release Candidate 3

by Anton Komlev

Hi, New TF-M Release Candidate 3 is tagged by TF-Mv1.3.0-RC3. Please update your repositories and report all issues you encountered. Best regards, Anton

5 years, 3 months

1
0
0 0

Announcement: New TF-M maintainers

by Anton Komlev

Hi Everyone, Let me announce the new maintainers of TF-M project: * Chris Brand aka UEWBot <chris.brand(a)cypress.com<mailto:chris.brand@cypress.com>> * Ken Liu aka KenLSoft <Ken.Liu(a)arm.com<mailto:Ken.Liu@arm.com>> * David Hu aka davidhuziji <David.Hu(a)arm.com<mailto:David.Hu@arm.com>> Previous maintainers convinced in your ability to push it forward thanks to your contribution and active involvement to the project development. At the same time, these maintainers are leaving the club: * Abhishek Pandit aka abhishek-pandit <abhishek.pandit(a)arm.com<mailto:abhishek.pandit@arm.com>> * Ashutosh Singh aka ashutoshksingh <ashutosh.singh(a)arm.com<mailto:ashutosh.singh@arm.com>> * Miklos Balint ara wmnt <miklos.balint(a)arm.com<mailto:miklos.balint@arm.com>> Huge thanks for your Blood, sweat and tears in bringing TF-M to the way it is now. Cheers, Anton

5 years, 3 months

1
0
0 0

Re: [TF-M] Regression observed in PSA Crypto after Mbed TLS upgrade to 2.25

by Summer Qin

Hi Alexander, Thanks for your information. For current TF-Mv1.3.0-RC1, yes, we have some extra failed test cases for crypto psa arch tests. They are 208, 211, 237, 243, and 244. We are now trying to fix them. 206 and 207 are our know issues. Details can be found in our tfm release failure analysis: https://developer.trustedfirmware.org/w/tf_m/release/psa_arch_crypto_test_f… https://developer.trustedfirmware.org/w/tf_m/release/psa_arch_crypto_test_f… Thanks, Summer ________________________________ From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> on behalf of Alexander.Moore--- via TF-M <tf-m(a)lists.trustedfirmware.org> Sent: Wednesday, March 24, 2021 3:55 PM To: David Hu <David.Hu(a)arm.com> Cc: nd <nd(a)arm.com>; tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org> Subject: Re: [TF-M] Regression observed in PSA Crypto after Mbed TLS upgrade to 2.25 What’s the build configuration on PSoC 64 with PSA Arch test: + BUILD_OPTS='-DTEST_PSA_API=CRYPTO -DTFM_PSA_API=ON -DTFM_ISOLATION_LEVEL=2' + cmake -S . -B build_clang_psoc64 -DTFM_PLATFORM=cypress/psoc64 -DTFM_TOOLCHAIN_FILE=toolchain_ARMCLANG.cmake -DCMAKE_BUILD_TYPE=Release -DTEST_PSA_API=CRYPTO -DTFM_PSA_API=ON -DTFM_ISOLATION_LEVEL=2 -- The C compiler identification is ARMClang 6.12.1 -- The ASM compiler identification is ARMCC We build both debug/release, and also use gcc/armclang, all four combinations give the same PSA Crypto test results. What’s the version of TF-M? Have you tried the latest one in master branch: * We are using the latest master (v1.2.0) and isolated the problem commit to be 28659c498c3bdbbc610959e7518bece5aaf72a19. What’s the version of PSA Arch test: * We are using the default tagged version associated with TF-M master branch, which is “8644bd0 musca_s1 support” Can you share more log of the failure test case: TEST: 206 | DESCRIPTION: Testing crypto hash functions APIs [Info] Executing tests from non-secure [Check 1] Test psa_hash_compute with SHA224 algorithm [Check 2] Test psa_hash_compute with SHA256 algorithm [Check 3] Test psa_hash_compute with SHA384 algorithm [Check 4] Test psa_hash_compute with SHA512 algorithm [Check 5] Test psa_hash_compute with small buffer size [Check 6] Test psa_hash_compute with invalid algorithm Failed at Checkpoint: 3 Actual: -135 Expected: -134 TEST RESULT: FAILED (Error Code=0x1) TEST: 207 | DESCRIPTION: Testing crypto hash functions APIs [Info] Executing tests from non-secure [Check 1] Test psa_hash_compare - SHA224 algorithm [Check 2] Test psa_hash_compare - SHA256 algorithm [Check 3] Test psa_hash_compare - SHA384 algorithm [Check 4] Test psa_hash_compare - SHA512 algorithm [Check 5] Test psa_hash_compare - incorrect hash [Check 6] Test psa_hash_compare - incorrect hash length [Check 7] Test psa_hash_compare - invalid algorithm Failed at Checkpoint: 3 Actual: -135 Expected: -134 TEST RESULT: FAILED (Error Code=0x1) TEST: 208 | DESCRIPTION: Testing crypto key derivation APIs [Info] Executing tests from non-secure [Check 1] Test psa_key_derivation_setup - ECDH + HKDF-SHA-256 [Check 2] Test psa_key_derivation_setup - ECDH, unknown KDF [Check 3] Test psa_key_derivation_setup - bad key derivation algorithm Failed at Checkpoint: 3 Actual: -134 Expected: -135 TEST RESULT: FAILED (Error Code=0x1) TEST: 211 | DESCRIPTION: Testing crypto hash functions APIs [Info] Executing tests from non-secure [Check 1] Test psa_hash_setup with SHA224 algorithm [Check 2] Test psa_hash_setup with SHA256 algorithm [Check 3] Test psa_hash_setup with SHA384 algorithm [Check 4] Test psa_hash_setup with SHA512 algorithm [Check 5] Test psa_hash_setup with Invalid hash algorithm Failed at Checkpoint: 3 Actual: -135 Expected: -134 TEST RESULT: FAILED (Error Code=0x1) TEST: 237 | DESCRIPTION: Testing crypto symmetric cipher APIs [Info] Executing tests from non-secure [Check 1] Test psa_cipher_finish - Encrypt - AES CBC_NO_PADDING [Check 2] Test psa_cipher_finish - Encrypt - AES CBC_NO_PADDING (Short in) [Check 3] Test psa_cipher_finish - Encrypt - AES CBC_PKCS7 [Check 4] Test psa_cipher_finish - Encrypt - AES CBC_PKCS7 (Short input) [Check 5] Test psa_cipher_finish - Encrypt - AES CTR [Check 6] Test psa_cipher_finish - Encrypt - AES CTR (short input) [Check 7] Test psa_cipher_finish - Encrypt - small output buffer size [Check 8] Test psa_cipher_finish - Decrypt - AES CBC_NO_PADDING [Check 9] Test psa_cipher_finish - Decrypt - AES CBC_NO_PADDING (Short in) Failed at Checkpoint: 8 Actual: -135 Expected: -137 TEST RESULT: FAILED (Error Code=0x1) TEST: 243 | DESCRIPTION: Testing crypto key derivation APIs [Info] Executing tests from non-secure [Check 1] Test psa_raw_key_agreement - ECDH SECP256R1 [Check 2] Test psa_raw_key_agreement - Small buffer size [Check 3] Test psa_raw_key_agreement - ECDH SECP384R1 [Check 4] Test psa_raw_key_agreement - Invalid usage [Check 5] Test psa_raw_key_agreement - Unknown KDF Failed at Checkpoint: 4 Actual: -134 Expected: -135 TEST RESULT: FAILED (Error Code=0x1) TEST: 244 | DESCRIPTION: Testing crypto key management APIs [Info] Executing tests from non-secure [Check 1] Test psa_copy_key - 16 Byte AES [Check 2] Test psa_copy_key - without copy usage [Check 3] Test psa_copy_key - invalid lifetime Failed at Checkpoint: 4 Actual: -136 Expected: -135 TEST RESULT: FAILED (Error Code=0x1) Thanks, Alex From: David Hu <David.Hu(a)arm.com> Sent: Monday, March 22, 2021 7:56 PM To: Moore Alexander (CSCA CSS ICW SW PSW 1) <Alexander.Moore(a)infineon.com> Cc: tf-m(a)lists.trustedfirmware.org; nd <nd(a)arm.com> Subject: RE: [TF-M] Regression observed in PSA Crypto after Mbed TLS upgrade to 2.25 Caution: This e-mail originated outside Infineon Technologies. Do not click on links or open attachments unless you validate it is safe<https://goto.infineon.com/SocialEngineering>. Hi Alexander, Thanks for reporting this issue. Can I ask for more details of the failures? * What’s the build configuration on PSoC 64 with PSA Arch test? * What’s the version of TF-M? Have you tried the latest one in master branch? * What’s the version of PSA Arch test? * Can you share more log of the failure test case? Thanks. Best regards, Hu Ziji From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org<mailto:tf-m-bounces@lists.trustedfirmware.org>> On Behalf Of Alexander.Moore--- via TF-M Sent: Tuesday, March 23, 2021 6:42 AM To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: [TF-M] Regression observed in PSA Crypto after Mbed TLS upgrade to 2.25 Hello, After “28659c49 Crypto: Upgrade Mbed TLS to 2.25” we see the following 7 PSA Crypto test failures on PSoC64 which were passing before this commit: TEST: 206 TEST: 207 TEST: 208 TEST: 211 TEST: 237 TEST: 243 TEST: 244 Are these failures expected? As far as we can tell, there is nothing else to be done associated with the 2.25 upgrade, i.e. the build automatically pulls 2.25 down, and there are no corresponding commits to psa-arch-tests to support the upgrade or any other changes necessary. Thanks, Alex

5 years, 3 months

2
2
0 0

Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed

by Thomas Törnblom

Never mind, I found the issue and have uploaded an updated patch. /Thomas Den 2021-03-30 kl. 15:17, skrev Thomas Törnblom via TF-M: > Hi Anton, > > Is it these issues that is causing the problems? > --- > In file included from > ..\platform\ext\accelerator\stm\..\..\..\ext\target\stm\common\stm32l5xx\Device\Include\stm32l5xx.h:106: > ..\platform\ext\accelerator\stm\..\..\..\ext\target\stm\common\stm32l5xx\Device\Include/stm32l562xx.h:1808:13: > warning: parameter 'pointer' not found in the function declaration > [-Wdocumentation] > * @param pointer on the vector table containing the reset handler > the function > ^~~~~~~ > ..\platform\ext\accelerator\stm\..\..\..\ext\target\stm\common\stm32l5xx\Device\Include/stm32l562xx.h:1808:13: > note: did you mean 'VectorTableAddr'? > * @param pointer on the vector table containing the reset handler > the function > ^~~~~~~ > VectorTableAddr > ..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:353:17: > warning: parameter 'dP' not found in the function declaration > [-Wdocumentation] > * @param[in] dP pΓÇÖs CRT exponent > ^~ > ..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:353:17: > note: did you mean 'dp'? > * @param[in] dP pΓÇÖs CRT exponent > ^~ > dp > ..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:354:17: > warning: parameter 'dQ' not found in the function declaration > [-Wdocumentation] > * @param[in] dQ qΓÇÖs CRT exponent > ^~ > ..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:354:17: > note: did you mean 'dp'? > * @param[in] dQ qΓÇÖs CRT exponent > ^~ > dp > ..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:1185:24: > warning: unused parameter 'p_rng' [-Wunused-parameter] > void *p_rng, > ^ > 4 warnings generated. > --- > > This has nothing to do with my patch but seems related to: > > PS > C:\Users\thomasto\Projects\tf-m8\trusted-firmware-m\platform\ext\target\stm\common\stm32l5xx\accelerator> > git log rsa_alt.c > commit 1ea82c0329f45204868df20a3bd8627286c0cdaa > Author: Michel Jaouen <michel.jaouen(a)st.com> > Date: Mon Jan 25 15:18:21 2021 +0100 > > Platform: stm: Add crypto accelerator support > > Change-Id: I7c0686c6f6470bebc7f258af125272d28bc4ce84 > Signed-off-by: Michel Jaouen <michel.jaouen(a)st.com> > > If it is not that issue, then please elaborate as I get exactly the > same result with or without my patch when building with armclang. > > /Thomas > > [ > Den 2021-03-30 kl. 13:27, skrev Anton Komlev via TF-M: >> >> Hi Michel, Thomas, >> >> The fix >> https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455 >> <https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455>fails >> for armclang. Please check the CI test. >> >> If it’s important feature of the release then could you check and fix >> it? Let me know if we can progress with RC3 without waiting for the fix. >> >> Thanks, >> >> Anton >> >> *From:*TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of >> *Michel JAOUEN via TF-M >> *Sent:* Monday, March 29, 2021 9:08 PM >> *To:* tf-m(a)lists.trustedfirmware.org >> *Subject:* Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 >> failed >> >> Thanks , it solved. >> >> Best Regards >> >> Michel >> >> *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:* lundi 29 mars 2021 17:37 >> *To:* tf-m(a)lists.trustedfirmware.org >> <mailto:tf-m@lists.trustedfirmware.org> >> *Subject:* Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 >> failed >> >> Apparently I have not tested this before. >> >> Check the fix at: >> https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455 >> <https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455> >> >> /Thomas >> >> Den 2021-03-29 kl. 16:35, skrev Michel JAOUEN via TF-M: >> >> Sure >> >> Variable $tfm_work point to trustedfirmware local dir. >> >> Here is my command >> >> cmake -S . -B build_dir -G"Unix Makefiles" >> >> -DTFM_PLATFORM=stm/stm32l562e_dk >> >> -DTFM_TOOLCHAIN_FILE=$tfm_work/toolchain_IARARM.cmake >> >> -DCMAKE_BUILD_TYPE=RelWithDebInfo >> >> -DTEST_S=ON -DTEST_NS=ON -DTFM_PSA_API=ON -DTFM_ISOLATION_LEVEL=2 >> >> Best regards >> >> Michel >> >> *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:* lundi 29 mars 2021 16:06 >> *To:* tf-m(a)lists.trustedfirmware.org >> <mailto:tf-m@lists.trustedfirmware.org> >> *Subject:* Re: [TF-M] TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 >> failed >> >> Hi Michel, >> >> Can you provide the cmake line and I'll have a look. >> >> That argument looks like a gcc argument not recognized by the IAR >> tools. >> >> Cheers, >> Thomas >> >> Den 2021-03-29 kl. 15:34, skrev Michel JAOUEN via TF-M: >> >> Hello, >> >> I got the following build issue when I build with IARAR, it >> occurs when build mbed-crypto >> >> IAR ANSI C/C++ Compiler V8.50.4.261/W32 for ARM >> >> Copyright 1999-2020 IAR Systems AB. >> >> Network license: 10.157.2.156 (STD) >> >> Command line error: Unexpected command line arguments: >> >> -Wno-unused-parameter >> >> Does someone else reproduce the issue ? >> >> Best regards >> >> -- >> >> *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> > -- *Thomas Törnblom*, /Product Engineer/ IAR Systems AB Box 23051, Strandbodgatan 1 SE-750 23 Uppsala, SWEDEN Mobile: +46 76 180 17 80 Fax: +46 18 16 78 01 E-mail: thomas.tornblom(a)iar.com <mailto:thomas.tornblom@iar.com> Website: www.iar.com <http://www.iar.com> Twitter: www.twitter.com/iarsystems <http://www.twitter.com/iarsystems>

5 years, 3 months

1
0
0 0

Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed

by Thomas Törnblom

Hi Anton, Is it these issues that is causing the problems? --- In file included from ..\platform\ext\accelerator\stm\..\..\..\ext\target\stm\common\stm32l5xx\Device\Include\stm32l5xx.h:106: ..\platform\ext\accelerator\stm\..\..\..\ext\target\stm\common\stm32l5xx\Device\Include/stm32l562xx.h:1808:13: warning: parameter 'pointer' not found in the function declaration [-Wdocumentation] * @param pointer on the vector table containing the reset handler the function ^~~~~~~ ..\platform\ext\accelerator\stm\..\..\..\ext\target\stm\common\stm32l5xx\Device\Include/stm32l562xx.h:1808:13: note: did you mean 'VectorTableAddr'? * @param pointer on the vector table containing the reset handler the function ^~~~~~~ VectorTableAddr ..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:353:17: warning: parameter 'dP' not found in the function declaration [-Wdocumentation] * @param[in] dP pΓÇÖs CRT exponent ^~ ..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:353:17: note: did you mean 'dp'? * @param[in] dP pΓÇÖs CRT exponent ^~ dp ..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:354:17: warning: parameter 'dQ' not found in the function declaration [-Wdocumentation] * @param[in] dQ qΓÇÖs CRT exponent ^~ ..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:354:17: note: did you mean 'dp'? * @param[in] dQ qΓÇÖs CRT exponent ^~ dp ..\platform\ext\target\stm\common\stm32l5xx\accelerator\rsa_alt.c:1185:24: warning: unused parameter 'p_rng' [-Wunused-parameter] void *p_rng, ^ 4 warnings generated. --- This has nothing to do with my patch but seems related to: PS C:\Users\thomasto\Projects\tf-m8\trusted-firmware-m\platform\ext\target\stm\common\stm32l5xx\accelerator> git log rsa_alt.c commit 1ea82c0329f45204868df20a3bd8627286c0cdaa Author: Michel Jaouen <michel.jaouen(a)st.com> Date: Mon Jan 25 15:18:21 2021 +0100 Platform: stm: Add crypto accelerator support Change-Id: I7c0686c6f6470bebc7f258af125272d28bc4ce84 Signed-off-by: Michel Jaouen <michel.jaouen(a)st.com> If it is not that issue, then please elaborate as I get exactly the same result with or without my patch when building with armclang. /Thomas [ Den 2021-03-30 kl. 13:27, skrev Anton Komlev via TF-M: > > Hi Michel, Thomas, > > The fix > https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455 > <https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455>fails > for armclang. Please check the CI test. > > If it’s important feature of the release then could you check and fix > it? Let me know if we can progress with RC3 without waiting for the fix. > > Thanks, > > Anton > > *From:*TF-M <tf-m-bounces(a)lists.trustedfirmware.org> *On Behalf Of > *Michel JAOUEN via TF-M > *Sent:* Monday, March 29, 2021 9:08 PM > *To:* tf-m(a)lists.trustedfirmware.org > *Subject:* Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed > > Thanks , it solved. > > Best Regards > > Michel > > *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:* lundi 29 mars 2021 17:37 > *To:* tf-m(a)lists.trustedfirmware.org > <mailto:tf-m@lists.trustedfirmware.org> > *Subject:* Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed > > Apparently I have not tested this before. > > Check the fix at: > https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455 > <https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455> > > /Thomas > > Den 2021-03-29 kl. 16:35, skrev Michel JAOUEN via TF-M: > > Sure > > Variable $tfm_work point to trustedfirmware local dir. > > Here is my command > > cmake -S . -B build_dir -G"Unix Makefiles" > > -DTFM_PLATFORM=stm/stm32l562e_dk > > -DTFM_TOOLCHAIN_FILE=$tfm_work/toolchain_IARARM.cmake > > -DCMAKE_BUILD_TYPE=RelWithDebInfo > > -DTEST_S=ON -DTEST_NS=ON -DTFM_PSA_API=ON -DTFM_ISOLATION_LEVEL=2 > > Best regards > > Michel > > *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:* lundi 29 mars 2021 16:06 > *To:* tf-m(a)lists.trustedfirmware.org > <mailto:tf-m@lists.trustedfirmware.org> > *Subject:* Re: [TF-M] TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed > > Hi Michel, > > Can you provide the cmake line and I'll have a look. > > That argument looks like a gcc argument not recognized by the IAR > tools. > > Cheers, > Thomas > > Den 2021-03-29 kl. 15:34, skrev Michel JAOUEN via TF-M: > > Hello, > > I got the following build issue when I build with IARAR, it > occurs when build mbed-crypto > > IAR ANSI C/C++ Compiler V8.50.4.261/W32 for ARM > > Copyright 1999-2020 IAR Systems AB. > > Network license: 10.157.2.156 (STD) > > Command line error: Unexpected command line arguments: > > -Wno-unused-parameter > > Does someone else reproduce the issue ? > > Best regards > > -- > > *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>

5 years, 3 months

1
0
0 0

Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed

by Anton Komlev

Hi Michel, Thomas, The fix https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455 fails for armclang. Please check the CI test. If it's important feature of the release then could you check and fix it? Let me know if we can progress with RC3 without waiting for the fix. Thanks, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Michel JAOUEN via TF-M Sent: Monday, March 29, 2021 9:08 PM To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed Thanks , it solved. Best Regards Michel 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: lundi 29 mars 2021 17:37 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed Apparently I have not tested this before. Check the fix at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455 /Thomas Den 2021-03-29 kl. 16:35, skrev Michel JAOUEN via TF-M: Sure Variable $tfm_work point to trustedfirmware local dir. Here is my command cmake -S . -B build_dir -G"Unix Makefiles" -DTFM_PLATFORM=stm/stm32l562e_dk -DTFM_TOOLCHAIN_FILE=$tfm_work/toolchain_IARARM.cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DTEST_S=ON -DTEST_NS=ON -DTFM_PSA_API=ON -DTFM_ISOLATION_LEVEL=2 Best regards Michel 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: lundi 29 mars 2021 16:06 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed Hi Michel, Can you provide the cmake line and I'll have a look. That argument looks like a gcc argument not recognized by the IAR tools. Cheers, Thomas Den 2021-03-29 kl. 15:34, skrev Michel JAOUEN via TF-M: Hello, I got the following build issue when I build with IARAR, it occurs when build mbed-crypto IAR ANSI C/C++ Compiler V8.50.4.261/W32 for ARM Copyright 1999-2020 IAR Systems AB. Network license: 10.157.2.156 (STD) Command line error: Unexpected command line arguments: -Wno-unused-parameter Does someone else reproduce the issue ? Best regards -- 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>

5 years, 3 months

1
0
0 0

Re: [TF-M] Technical Forum call - April 1 (not a joke :)

by David Wang

Hi Anton, If we still have slot, I'd like to share some thoughts and have a discussion for the TF-M documentation structure. It should be less than 20 mins. Thanks. Regards, David Wang From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Mingyang Sun via TF-M Sent: Monday, March 29, 2021 11:15 AM 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 - April 1 (not a joke :) Hi Anton, I'd like give a short session on "stateless handle and service in TF-M", about 20min. Regards, Mingyang 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: Friday, March 26, 2021 6:57 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] Technical Forum call - April 1 (not a joke :) Hi, The next Technical Forum is planned on Thursday, April 1 , 07:00-08:00 UTC (Asia time zone). Please mine the gap of the time change in Europe! Please reply on this email with your proposals for agenda topics. Recording and slides of previous meetings are here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best regards, Anton

5 years, 3 months

1
0
0 0

Re: [TF-M] Issues with alignment and buffer locations

by Ken Liu

Hi Jamie, Could help to provide the details so that we can see what the problem is? Looks like you mentioned two problems here, one for the un-aligned memory accessing and another is the FLASH read/write. For the memory alignment, to ensure the isolation setting all sections should be 32-bytes aligned; and the stack-alignment is 8 bytes. Other contents are set as default, the toolchain should have handled them correctly. Please provide the details, thank you! /Ken From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Jamie Mccrae via TF-M Sent: Monday, March 29, 2021 10:19 PM To: tf-m(a)lists.trustedfirmware.org Subject: [TF-M] Issues with alignment and buffer locations Hi, There seems to be a large oversight in the TF-M codeline relating to buffer alignment and locations of buffers, in terms of buffer alignment, some ARM-based silicon has restrictions on buffer alignment, generally 4-byte boundaries, this means that if a non-4 byte boundary address, buffer or data size is provided, the operation cannot be completed. Another issue is that some ARM-based silicon has restrictions on where data can be located, e.g. in RAM only for writing and not from other address spaces. I am currently trying to get TF-M working on a Nordic nRF53-based designed and have encountered these issues many times, and can see no way to set an alignment, data size or address space limitation in the whole code line which I find to be quite displeasing given that both the silicon and software are ARM-based, I would expect the software you give for silicon based on your reference designs to actually work with it out of the box rather than need lots of work to have these limitations supported. On Nordic silicon, data can only be written and read from RAM e.g. you cannot write to flash from a flash offset, and writes must be 4-byte aligned and 4-byte sized (the QSPI functionality is being used here). So I am emailing here to ask: what is the suggestion for dealing with this? Why does the baseline project not (from what I can see) have any sort of support for this? Thanks, Jamie THIS MESSAGE, ANY ATTACHMENT(S), AND THE INFORMATION CONTAINED HEREIN MAY BE PROPRIETARY TO LAIRD CONNECTIVITY, INC. AND/OR ANOTHER PARTY, AND MAY FURTHER BE INTENDED TO BE KEPT CONFIDENTIAL. IF YOU ARE NOT THE INTENDED RECIPIENT, PLEASE DELETE THE EMAIL AND ANY ATTACHMENTS, AND IMMEDIATELY NOTIFY THE SENDER BY RETURN EMAIL. THIS MESSAGE AND ITS CONTENTS ARE THE PROPERTY OF LAIRD CONNECTIVITY, INC. AND MAY NOT BE REPRODUCED OR USED WITHOUT THE EXPRESS WRITTEN CONSENT OF LAIRD CONNECTIVITY, INC.

5 years, 3 months

1
0
0 0

Re: [TF-M] TF-M v1.3.0 Release Candidate 2

by Anton Komlev

Hi, New TF-M Release Candidate 2 is tagged by TF-Mv1.3.0-RC2. Please update all repositories as it contain fixes for issues found in RC1. Best regards, Anton

5 years, 3 months

1
0
0 0

Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed

by Michel JAOUEN

Thanks , it solved. Best Regards Michel From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Thomas Törnblom via TF-M Sent: lundi 29 mars 2021 17:37 To: tf-m(a)lists.trustedfirmware.org Subject: Re: [TF-M] FW: TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed Apparently I have not tested this before. Check the fix at: https://review.trustedfirmware.org/c/TF-M/trusted-firmware-m/+/9455 /Thomas Den 2021-03-29 kl. 16:35, skrev Michel JAOUEN via TF-M: Sure Variable $tfm_work point to trustedfirmware local dir. Here is my command cmake -S . -B build_dir -G"Unix Makefiles" -DTFM_PLATFORM=stm/stm32l562e_dk -DTFM_TOOLCHAIN_FILE=$tfm_work/toolchain_IARARM.cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DTEST_S=ON -DTEST_NS=ON -DTFM_PSA_API=ON -DTFM_ISOLATION_LEVEL=2 Best regards Michel 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: lundi 29 mars 2021 16:06 To: tf-m(a)lists.trustedfirmware.org<mailto:tf-m@lists.trustedfirmware.org> Subject: Re: [TF-M] TF-Mv1.3.0-RC1 => build with IARARM 8.5.4 failed Hi Michel, Can you provide the cmake line and I'll have a look. That argument looks like a gcc argument not recognized by the IAR tools. Cheers, Thomas Den 2021-03-29 kl. 15:34, skrev Michel JAOUEN via TF-M: Hello, I got the following build issue when I build with IARAR, it occurs when build mbed-crypto IAR ANSI C/C++ Compiler V8.50.4.261/W32 for ARM Copyright 1999-2020 IAR Systems AB. Network license: 10.157.2.156 (STD) Command line error: Unexpected command line arguments: -Wno-unused-parameter Does someone else reproduce the issue ? Best regards -- 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>

5 years, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M