Hi Miklos,
Thank you for the roadmap info. I’ll check this out and provide feedback in a separate email.
Yes, my concern is regarding the few dozen cycles of overhead. No, this is not a major limitation but it does seem needlessly wasteful to me.
I think your proposal to alter the behavior of TZ_LoadContext_S as you suggest is an excellent idea. My understanding of the TZ_LoadContext_S semantics is “until the next TZ_LoadContext_S call, all calls into the SPM will be from this context”. If that is a correct understanding, then assuming the previously active MemoryId should be stored seems like a safe and always true inference.
Alan
On Feb 7, 2019, at 2:42 AM, Miklos Balint via TF-M tf-m@lists.trustedfirmware.org wrote:
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
Alan,
Thanks for the feedback on this, I'll add a note to the proposal and a Phabricator task to adjust the implementation.
Regards Miklos
-----Original Message----- From: DeMars, Alan ademars@ti.com Sent: 07 February 2019 14:16 To: Miklos Balint Miklos.Balint@arm.com Cc: tf-m@lists.trustedfirmware.org; nd nd@arm.com Subject: Re: [TF-M] [Tf-m] [EXTERNAL] Re: Non-secure Client Management
Hi Miklos,
Thank you for the roadmap info. I’ll check this out and provide feedback in a separate email.
Yes, my concern is regarding the few dozen cycles of overhead. No, this is not a major limitation but it does seem needlessly wasteful to me.
I think your proposal to alter the behavior of TZ_LoadContext_S as you suggest is an excellent idea. My understanding of the TZ_LoadContext_S semantics is “until the next TZ_LoadContext_S call, all calls into the SPM will be from this context”. If that is a correct understanding, then assuming the previously active MemoryId should be stored seems like a safe and always true inference.
Alan
On Feb 7, 2019, at 2:42 AM, Miklos Balint via TF-M tf-m@lists.trustedfirmware.org wrote:
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__trustzon e__functions.html
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_manage m 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