- TF-M - lists.trustedfirmware.org

Re: [TF-M] Supporting integrated Non-Secure RTOS applications that use the FPU

by Kevin Townsend

On Wed, 21 Apr 2021 at 18:56, Glaropoulos, Ioannis via TF-M < tf-m(a)lists.trustedfirmware.org> wrote: > I would like to ask the community whether these issues have been raised in > the past – and if so, please, inform me what the conclusions have been. Are > there current activities that attempt to address the problems raised above? > Not been able to fully utilize the FP context stacking in Non-Secure Zephyr > applications that integrate with TF-M removes value of our TF-M based > solutions. > > > > Thanks! I am looking forward to hearing the thoughts of the community. > > Hi Ioannis, The previous technical forum call did discuss FP usage ... I don't think you were on the call at the time, but the presentation and video can be viewed here, and should point to the people to follow up with here on the mailing list of on phabricator, etc. Presentation: https://www.trustedfirmware.org/docs/FP-support-in-TF-M.pdf Video link(s) available here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ Best rehards, Kevin

4 years, 9 months

2
2
0 0

Removal of the nRF5340 PDK platform

by Głąbek, Andrzej

Hello, As announced on March 3 (see https://lists.trustedfirmware.org/pipermail/tf-m/2021-March/001516.html) and in the absence of objections, the nRF5340 PDK platform (nordic_nrf/nrf5340pdk_nrf5340_cpuapp) has been deprecated in the v1.3.0 release and the release is the last one to support this platform. Today, the code and documentation related to this platform have been removed from TF-M. Best regards, Andrzej Głąbek

4 years, 9 months

1
0
0 0

Re: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface

by Anton Komlev

Hi, Here is the proposal to restructure TF-M following the intention to split it on the essential part and supplementary items with better logical separation. The proposed new structure, composed from 4 repositories is following: 1. trusted-firmware-m (The essential TF-M core: SPM + PSA partitions and interface. Documentation) 2. tf-m-tests * regression * other test 3. tf-m-tools (additional tools and place for integration glue with 3rd party frameworks) * cmsis * fuzzer * Iat-verifier * ... 4. tf-m-extras (extra components, used in a specific case, but optional for common use) * examples i. NS ii. S * S-partitions - (3rd party production partitions) The questions to the community: 1. Any concern or dependency on the proposed restructure? 2. Shall we treat tests separately or as one of the extra component? Effectively the question are tests deserves a dedicated repo or a folder in tf-m-extra? 3. Better name for tf-m-extra? tf-m-apps? Looking for your comments, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Anton Komlev via TF-M Sent: Thursday, April 15, 2021 12:24 PM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: Re: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface Thanks, David, The connected job is to rename tf-m-tests repo to something more general to keep supplementary code and not interfere it with TF-M core on secure side. The first candidate was tf-m-ns to reflect the collection of non-secure elements but it might confuse when using it for custom and examples of secure partitions. Thoughts and proposals for the repo naming are welcome. Regards, Anton 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: Thursday, April 15, 2021 9:12 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] [Ask for review] Decouple NS specific code from TF-M NS interface Hi all, May I ask you to take a look at the following patch set to decouple NS specific code from TF-M NS interface? https://review.trustedfirmware.org/q/topic:%22decouple-ns-interface%22+(sta… The decoupled NS code is moved from trusted-firmware-m repo to tf-m-tests repo, as an example of NS implementation. https://review.trustedfirmware.org/q/topic:%22add-ns-code%22+(status:open%2… The purpose of this change is to make it more flexible and simple to integrate NS OS with TF-M NS interface. Currently TF-M provides some reference implementations of NS interface for NS OS integration. However, it may have limitations during NS OS integration as various NS OSes/application usages prefer different implementations. Therefore, those NS OS specific code is removed from TF-M interface for NS clients in this patch set. The removed NS code includes NS interface lock ops, os wrappers and NS test specific implementation. Those NS code can be taken as an example in tf-m-tests. NS developers can follow or replace them during integration with TF-M, according to NS OS implementation and actual scenarios, without hacking trusted-firmware-m repo. This patch set doesn't change the current integration scheme. Instead, it exports the "tfm_ns_interface_dispatch()" API and enables NS OS to implement it according to NS OS and application specific requirement, such as NS interface lock operations. Any comment is welcome! Best regards, Hu Ziji

4 years, 9 months

1
0
0 0

Technical Forum call - April 29

by Anton Komlev

Hi, The next Technical Forum is planned on Thursday, April 29 , 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, 9 months

1
0
0 0

Supporting integrated Non-Secure RTOS applications that use the FPU

by Glaropoulos, Ioannis

Hi, I would like to raise an issue around Floating Point support in the context of Non-Secure RTOS-based applications integrated with TF-M. The problem: We cannot fully (and easily) utilize the cortex-m Floating point features in Zephyr running together with TF-M. (Note, this has little to do with TF-M not having a secure floating point support today - we focus entirely on using the FPU in non-secure domain.) Description of the case: In Zephyr multi-thread environment we enable the FP co-processor and the advanced context-control features in Cortex-M * Automatic state preservation * Lazy stacking Zephyr threads are free to use the floating point registers; the automatic state preservation ensures the caller-saved registers are preserved and the context-switch routines ensure the callee-saved registers are preserved as well. The situation becomes interesting when Zephyr threads with active FP context are doing calls to the TF-M services. In such a scenario, it may happen that the TF-M secure threads will need to preserve the FP context themselves, during a non-secure interrupt that accesses the FP registers. Currently this triggers a TF-M system crash, as TF-M does not enable the FP co-processor. I guess this could be solved by enabling the FP co-processor in TF-M. Even in this case, the TF-M would need to preserve the FP context state when switching between threads in Secure PendSV, so Non-Secure interrupts (and potential Non-Secure reschedule actions) would not interfere with FP state preservation. What we see today is that the Non-Secure FP context is not preserved during TF-M thread switches, leading to weird situations such as when the lazy state preservation active bit is set in Secure thread mode; which should not be the case. I would like to ask the community whether these issues have been raised in the past - and if so, please, inform me what the conclusions have been. Are there current activities that attempt to address the problems raised above? Not been able to fully utilize the FP context stacking in Non-Secure Zephyr applications that integrate with TF-M removes value of our TF-M based solutions. Thanks! I am looking forward to hearing the thoughts of the community. Ioannis

4 years, 9 months

1
0
0 0

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

by Kevin Peng

Hi Andrew, - Are there other important uses for the query API? I cannot really answer this question. But as you have mentioned, when this query API is provided, it couldn't be always reliable - the status could be changed between query and control. And I also think the nested critical section could really happen (this was the main use case of the IRQ status I guess): A Partition thread and a FLIH function for IRQ1 both wants to mask IRQ2 because they both have data shared with IRQ2. This means the IRQ1 and Partition thread have shared data. Then the Secure Partition thread should mask both IRQ1 and IRQ2 when it accesses the shared data. So IMHO, I don't think Secure Partitions need to the status of IRQs. Best Regards, Kevin -----Original Message----- From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of Andrew Thoelke via TF-M Sent: Wednesday, April 14, 2021 6:15 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 Hi Kevin, In light of the concern regarding atomicity and race conditions, is there a real benefit to retaining the behaviour of psa_irq_disable() returning the prior status. By defining the API this way, it forces every implementation to ensure that the test-and-disable action of this API is atomic with respect to all interrupts in the system (as these could modify the target interrupt state between the test and the disable). Even if TF-M today does this as a result of using an SVC to implement this API, that does not imply that all implementations will need to do that. If we remove the return value from psa_irq_disable(), this also simplifies the TF-M implementation using the CMSIS NVIC_DisableIRQ() function. This would leave us with: void psa_irq_enable(psa_signal_t irq_signal); void psa_irq_disable(psa_signal_t irq_signal); Is it problematic to provide no mechanism to query the state? Are the following use cases for psa_irq_is_enabled() important enough to include this API: * Diagnostics (e.g. when debugging) * Initialisation * Recovery from error conditions The last two of these shouldn't require such an API, as the software should be aware of the peripheral and interrupt state at these points - but the API might make coding these easier? Are there other important uses for the query API? Regards, Andrew -----Original Message----- From: Kevin Peng <Kevin.Peng(a)arm.com> Sent: 13 April 2021 05:03 To: Andrew Thoelke <Andrew.Thoelke(a)arm.com>; tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: RE: Arm Firmware Framework for M 1.1 Extensions Alpha specification 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 -- TF-M mailing list TF-M(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m

4 years, 9 months

1
0
0 0

Re: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface

by Anton Komlev

Thanks, David, The connected job is to rename tf-m-tests repo to something more general to keep supplementary code and not interfere it with TF-M core on secure side. The first candidate was tf-m-ns to reflect the collection of non-secure elements but it might confuse when using it for custom and examples of secure partitions. Thoughts and proposals for the repo naming are welcome. Regards, Anton From: TF-M <tf-m-bounces(a)lists.trustedfirmware.org> On Behalf Of David Hu via TF-M Sent: Thursday, April 15, 2021 9:12 AM To: tf-m(a)lists.trustedfirmware.org Cc: nd <nd(a)arm.com> Subject: [TF-M] [Ask for review] Decouple NS specific code from TF-M NS interface Hi all, May I ask you to take a look at the following patch set to decouple NS specific code from TF-M NS interface? https://review.trustedfirmware.org/q/topic:%22decouple-ns-interface%22+(sta… The decoupled NS code is moved from trusted-firmware-m repo to tf-m-tests repo, as an example of NS implementation. https://review.trustedfirmware.org/q/topic:%22add-ns-code%22+(status:open%2… The purpose of this change is to make it more flexible and simple to integrate NS OS with TF-M NS interface. Currently TF-M provides some reference implementations of NS interface for NS OS integration. However, it may have limitations during NS OS integration as various NS OSes/application usages prefer different implementations. Therefore, those NS OS specific code is removed from TF-M interface for NS clients in this patch set. The removed NS code includes NS interface lock ops, os wrappers and NS test specific implementation. Those NS code can be taken as an example in tf-m-tests. NS developers can follow or replace them during integration with TF-M, according to NS OS implementation and actual scenarios, without hacking trusted-firmware-m repo. This patch set doesn't change the current integration scheme. Instead, it exports the "tfm_ns_interface_dispatch()" API and enables NS OS to implement it according to NS OS and application specific requirement, such as NS interface lock operations. Any comment is welcome! Best regards, Hu Ziji

4 years, 10 months

1
0
0 0

[Ask for review] Decouple NS specific code from TF-M NS interface

by David Hu

Hi all, May I ask you to take a look at the following patch set to decouple NS specific code from TF-M NS interface? https://review.trustedfirmware.org/q/topic:%22decouple-ns-interface%22+(sta… The decoupled NS code is moved from trusted-firmware-m repo to tf-m-tests repo, as an example of NS implementation. https://review.trustedfirmware.org/q/topic:%22add-ns-code%22+(status:open%2… The purpose of this change is to make it more flexible and simple to integrate NS OS with TF-M NS interface. Currently TF-M provides some reference implementations of NS interface for NS OS integration. However, it may have limitations during NS OS integration as various NS OSes/application usages prefer different implementations. Therefore, those NS OS specific code is removed from TF-M interface for NS clients in this patch set. The removed NS code includes NS interface lock ops, os wrappers and NS test specific implementation. Those NS code can be taken as an example in tf-m-tests. NS developers can follow or replace them during integration with TF-M, according to NS OS implementation and actual scenarios, without hacking trusted-firmware-m repo. This patch set doesn't change the current integration scheme. Instead, it exports the "tfm_ns_interface_dispatch()" API and enables NS OS to implement it according to NS OS and application specific requirement, such as NS interface lock operations. Any comment is welcome! Best regards, Hu Ziji

4 years, 10 months

1
0
0 0

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

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

4 years, 10 months

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-M