Miklos,
In regards to the roadmap, just to confirm my understanding, does the "[TF-M Core] Interrupt Handling Enhancements" bullet due in Q1`19 refer to the interrupt support as described in section 3.4 "Secure peripheral drivers" of the PSA Firmware Framework document?
When will SP pre-emption and blocking be supported? A secure peripheral driver that doesn't allow the NS thread to block while waiting for something to complete is a non-starter for us. As well, a SP thread that can't be pre-empted by a higher priority NS thread is almost as unpalatable for us.
Alan
-----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Miklos Balint via TF-M Sent: Thursday, February 07, 2019 2:43 AM To: tf-m@lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [Tf-m] [EXTERNAL] Re: Non-secure Client Management
Hi Alan,
https://developer.trustedfirmware.org/w/tf_m/planning/ has a roadmap of planned feature support by calendar quarter. NSPM for the thread-based design is not explicitly highlighted but I would expect it to be implemented as part of the Q2 SPM work or Q3 Scheduler work the latest. Any feedback on that or any other aspect of the roadmap is very welcome so we can take that into account when updating the plans.
For the TZ functions, please note that these are not proprietary to TF-M but form a standard CMSIS API, a generic RTOS feature for TrustZone-enabled devices: https://www.keil.com/pack/doc/CMSIS/Core/html/group__context__trustzone__fun...
Since these calls are direct function calls between NSPE and SPE, the overhead should be in the order of a few dozen clock cycles each, not much more than regular RTOS context switch hooks that would be available in several RTOSes. Are you concerned that this overhead is a major limitation?
If so, one enhancement TF-M could provide to support a simplified non-CMSIS-compliant NSPE RTOS implementation is for TZ_LoadContext_S to implement the functionality you described for "SwitchContext", taking only the new MemoryId as argument - the old id is stored in the NSPM database anyway, so the context to be Stored in this case can be inferred by TF-M. If the new context is not secure-accessing, FreeContext can be used as defined by CMSIS. This way TF-M does not introduce proprietary new functions for functionality already defined by the standard. Please note that this solution would still need to be analysed for security implications as TF-M would be making additional assumptions on NSPE state - although I don't see a reason for concern at this point.
/M
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of DeMars, Alan via TF-M Sent: 03 February 2019 15:18 To: Ken Liu (Arm Technology China) Ken.Liu@arm.com Cc: nd nd@arm.com; tf-m@lists.trustedfirmware.org Subject: Re: [Tf-m] [EXTERNAL] Re: Non-secure Client Management
Ken,
Thank you for your prompt response. Please see my replies below.
Alan
Hi Alan, The proposed APIs are implemented for library mode. It will not work under IPC mode in 'feature-ipc' branch. The support of NSPM for IPC will come later.
Is their a feature rollout schedule that I can follow?
The TZ_LoadContext_S() and TZ_StoreContext_S() need to be called every time while secure service accessed NS thread get entering/leaving. It is not combined into one function, because not all NS threads need to access secure service. For those NS threads which do not need to access secure service, these TZ_ APIs are unnecessary to be called. For example, if NS scheduler switches from one secure service accessed thread into the other generic thread, only TZ_StoreContext_S() needs to be called before context switching.
To avoid the rather burdensome overhead of calling into the SPM twice on those NS context switches in which either the leaving or entering contexts are secure accessing threads, I propose that a NULL TZ_MemoryId_t be defined so that a single TZ_SwitchContext_S() function with two TZ_MemoryId_t arguments can be called. The NULL TZ_MemoryId_t would be passed to identify an entering or leaving context that is not secure accessing.
The method of blocking the caller client is based on scenarios. If there are some 'wait' is necessary while secure service is working (waiting for secure hardware IRQ as an example), the method you mentioned may be involved (special return value with an NS IRQ notification). This functionality is not in place right now.
-Ken
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of DeMars, Alan via TF-M Sent: Sunday, February 3, 2019 9:17 AM To: tf-m@lists.trustedfirmware.org Subject: [Tf-m] Non-secure Client Management
Regarding the Non-secure Client Management proposal:
https://developer.trustedfirmware.org/w/tf_m/design/ns_client_managem ent/
I notice that the veneers for the proposed APIs are in s_veneers.o. Does this mean that the proposal has been adopted and implemented? Is it functional in the current feature-ipc branch?
I have a question about the TZ_LoadContext_S() and TZ_StoreContext_S() APIs: Is it expected that each context switch in the NS world will be signaled by calls to each of these APIs indicating the "entering" context and "leaving" context respectively? If so, then why not collapse these two APIs into one called TZ_SwitchContext__S() and pass both the "entering" and "leaving" TZ_MemoryId_t's as arguments?
Or is TZ_StoreContext_S() only to be called when a NS context will never call into the SPM again? If that is the case, why isn't TZ_FreeModuleContext_S() sufficient?
Regarding the "Concurrent secure service requests" discussion, what does "a non-secure client is blocked on an asynchronous secure service completion"? Would this be achieved by a special return status from psa_call() indicating that the current service request is in process and will complete later on? The psa_call() calling thread would then block on a semaphore that would be released by a dedicated NS IRQ interrupt? Is any of this functionality in place yet?
Alan
Alan,
Regarding "Interrupt handling enhancements" in Q1'19:
Yes, the primary goal for this quarter is to support secure interrupt handling in the thread-based design in line with the PSA FF document, while a secondary aim is to refine/upstream the prototype already on review for the library model based on my design proposal https://developer.trustedfirmware.org/w/tf_m/design/secure_partition_interru...
The current implementation of SPM only associates at most a single MMIO region to a partition, and at present only "named_region" is supported. This is a limitation compared to the description in section 3.4, but I don't see that as being critical for the first implementation; for level 1 isolation it should be fairly easy to add support for multiple ones if needed.
Regards Miklos
-----Original Message----- From: DeMars, Alan ademars@ti.com Sent: 07 February 2019 22:02 To: Miklos Balint Miklos.Balint@arm.com Cc: nd nd@arm.com; tf-m@lists.trustedfirmware.org Subject: RE: [Tf-m] [EXTERNAL] Re: Non-secure Client Management
Miklos,
In regards to the roadmap, just to confirm my understanding, does the "[TF-M Core] Interrupt Handling Enhancements" bullet due in Q1`19 refer to the interrupt support as described in section 3.4 "Secure peripheral drivers" of the PSA Firmware Framework document?
When will SP pre-emption and blocking be supported? A secure peripheral driver that doesn't allow the NS thread to block while waiting for something to complete is a non-starter for us. As well, a SP thread that can't be pre-empted by a higher priority NS thread is almost as unpalatable for us.
Alan
-----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Miklos Balint via TF-M Sent: Thursday, February 07, 2019 2:43 AM To: tf-m@lists.trustedfirmware.org Cc: nd Subject: Re: [TF-M] [Tf-m] [EXTERNAL] Re: Non-secure Client Management
Hi Alan,
https://developer.trustedfirmware.org/w/tf_m/planning/ has a roadmap of planned feature support by calendar quarter. NSPM for the thread-based design is not explicitly highlighted but I would expect it to be implemented as part of the Q2 SPM work or Q3 Scheduler work the latest. Any feedback on that or any other aspect of the roadmap is very welcome so we can take that into account when updating the plans.
For the TZ functions, please note that these are not proprietary to TF-M but form a standard CMSIS API, a generic RTOS feature for TrustZone-enabled devices: https://www.keil.com/pack/doc/CMSIS/Core/html/group__context__trustzone__fun...
Since these calls are direct function calls between NSPE and SPE, the overhead should be in the order of a few dozen clock cycles each, not much more than regular RTOS context switch hooks that would be available in several RTOSes. Are you concerned that this overhead is a major limitation?
If so, one enhancement TF-M could provide to support a simplified non-CMSIS-compliant NSPE RTOS implementation is for TZ_LoadContext_S to implement the functionality you described for "SwitchContext", taking only the new MemoryId as argument - the old id is stored in the NSPM database anyway, so the context to be Stored in this case can be inferred by TF-M. If the new context is not secure-accessing, FreeContext can be used as defined by CMSIS. This way TF-M does not introduce proprietary new functions for functionality already defined by the standard. Please note that this solution would still need to be analysed for security implications as TF-M would be making additional assumptions on NSPE state - although I don't see a reason for concern at this point.
/M
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of DeMars, Alan via TF-M Sent: 03 February 2019 15:18 To: Ken Liu (Arm Technology China) Ken.Liu@arm.com Cc: nd nd@arm.com; tf-m@lists.trustedfirmware.org Subject: Re: [Tf-m] [EXTERNAL] Re: Non-secure Client Management
Ken,
Thank you for your prompt response. Please see my replies below.
Alan
Hi Alan, The proposed APIs are implemented for library mode. It will not work under IPC mode in 'feature-ipc' branch. The support of NSPM for IPC will come later.
Is their a feature rollout schedule that I can follow?
The TZ_LoadContext_S() and TZ_StoreContext_S() need to be called every time while secure service accessed NS thread get entering/leaving. It is not combined into one function, because not all NS threads need to access secure service. For those NS threads which do not need to access secure service, these TZ_ APIs are unnecessary to be called. For example, if NS scheduler switches from one secure service accessed thread into the other generic thread, only TZ_StoreContext_S() needs to be called before context switching.
To avoid the rather burdensome overhead of calling into the SPM twice on those NS context switches in which either the leaving or entering contexts are secure accessing threads, I propose that a NULL TZ_MemoryId_t be defined so that a single TZ_SwitchContext_S() function with two TZ_MemoryId_t arguments can be called. The NULL TZ_MemoryId_t would be passed to identify an entering or leaving context that is not secure accessing.
The method of blocking the caller client is based on scenarios. If there are some 'wait' is necessary while secure service is working (waiting for secure hardware IRQ as an example), the method you mentioned may be involved (special return value with an NS IRQ notification). This functionality is not in place right now.
-Ken
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of DeMars, Alan via TF-M Sent: Sunday, February 3, 2019 9:17 AM To: tf-m@lists.trustedfirmware.org Subject: [Tf-m] Non-secure Client Management
Regarding the Non-secure Client Management proposal:
https://developer.trustedfirmware.org/w/tf_m/design/ns_client_managem ent/
I notice that the veneers for the proposed APIs are in s_veneers.o. Does this mean that the proposal has been adopted and implemented? Is it functional in the current feature-ipc branch?
I have a question about the TZ_LoadContext_S() and TZ_StoreContext_S() APIs: Is it expected that each context switch in the NS world will be signaled by calls to each of these APIs indicating the "entering" context and "leaving" context respectively? If so, then why not collapse these two APIs into one called TZ_SwitchContext__S() and pass both the "entering" and "leaving" TZ_MemoryId_t's as arguments?
Or is TZ_StoreContext_S() only to be called when a NS context will never call into the SPM again? If that is the case, why isn't TZ_FreeModuleContext_S() sufficient?
Regarding the "Concurrent secure service requests" discussion, what does "a non-secure client is blocked on an asynchronous secure service completion"? Would this be achieved by a special return status from psa_call() indicating that the current service request is in process and will complete later on? The psa_call() calling thread would then block on a semaphore that would be released by a dedicated NS IRQ interrupt? Is any of this functionality in place yet?
Alan
-- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m
tf-m@lists.trustedfirmware.org
-
DeMars, Alan -
Miklos Balint