Hi Erik,
Your mail contains quite a few questions. I'll try to give an overview in the topic you are asking, hoping that it is going to answer most (hopefully all) questions. If there is anything left unanswered, please follow up.
So currently TF-M supports two working model: IPC model, and Library model. Library model has no scheduling on the secure side, secure services are called like normal functions.
The IPC model contains a simple scheduler. (IPC model is an implementation of the PSA Firmware Framework for M (PSA-FF-M):
https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Architect/DEN0063-PSA_Firmware_Framework-1.0.0-2.pdf?revision=2d1429fa-4b5b-461a-a60e-4ef3d8f7f4b4 ) In this model, all the secure partitions have a runtime context associated with
them. They have a separate stack, and their runtime state is saved when they are not scheduled by the Secure scheduler. This means that the number of secure contexts is determined compile time.
'Cooperative Scheduling Rules' document is a proposal of how a Non-Secure and a Secure scheduler should work together, to efficiently handle secure and non-secure asynchronous events. Currently The Secure scheduler has no knowledge of the
state of the NS scheduler, and vice-versa. There is a roadmap item 'Scheduler - Initial Support' (currently without deadline) at
https://developer.trustedfirmware.org/w/tf_m/planning/ which refers to this.
The RTOS Thread Context Management API implementation had been added to TF-M, to support a feature called TF-M Non-Secure client identification. It is used by the
/**
* \brief Stores caller's client id in state context
*/
void tfm_core_get_caller_client_id_handler(const uint32_t svc_args[]);
API that is available for the secure services. Through this API secure services can distinguish Non-Secure clients.
TF-M manages a database of clients reported by the Non secure software (through the TZ_*APIs), and also tracks the ID of the currently active client. That client ID is returned by 'tfm_core_get_caller_client_id_handler' (in case the Secure
Service was called from Non-Secure code)
Please note that the 'tfm_core_get_caller_client_id_handler' API is only supported in Library model. The TZ_* APIs are implemented in the NSPM module: secure_fw/core/tfm_nspm_func.c.
The IPC model's implementation of the NSPM module is empty: secure_fw/core/tfm_nspm_ipc.c
The original idea behind the RTOS Thread Context Management API is that the Secure context creation (allocating stack, and other supporting data structures) and destruction is initiated from the Non-Secure code. The number of active secure
contexts is decided by the NS code in run time (of course if there is no more resource, the context creation fails). On scheduling, the non-secure SW notifies the secure code, to activate the context for the thread to be scheduled. This results in setting
the secure stack pointer to the desired context (hence the “prepare”). After the NS Scheduler returns to the thread, the Secure or the Non-Secure code continues execution, depending on whether Secure, or Non-Secure execution had been interrupted by the NS
scheduling.
Neither the single secure context design of the library model, and the above described design of the IPC model supports this approach, and that's why the semantics of the APIs in TF-M are different in TF-M.
Regards,
Mate
From: TF-M <tf-m-bounces@lists.trustedfirmware.org>
On Behalf Of Shreve, Erik via TF-M
Sent: Wednesday, March 11, 2020 3:07 PM
To: tf-m@lists.trustedfirmware.org
Subject: [TF-M] Cooperative Scheduling Rules and CMSIS tz_context
Hello everyone, I’m new to the list. Quick introduction: I work at Texas Instruments and I’m investigating TFM for use in some of our platforms here.
I’m trying to understand the scheduling and task architecture for PSA and the TFM implementation and how that intersects with NS tasks.
I found the following:
https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone__functions.html
The existing TFM implementation doesn’t seem to do much with the tz_context interface. It looks like it tracks which NS client is active, but I don’t see where it uses that information to do anything.
Am I missing something?
I’d like to understand more about where TFM is going with the tz_context interface.
Will there be a tz_context focused scheduler? I can imagine one where the SPM associates NS clients with running Secure Partitions and resumes execution of a running a Secure Partition when the NS RTOS indicates the NS
client is “active.” But it isn’t clear to me if this is the direction or not.
I note that the text for TZ_LoadContext_S says “**Prepare** the secure context for execution so that a thread in the non-secure state can call secure library modules.” Preparing sounds different than immediate execution.
Are there other documents I can read or source implementations I can reference to get more of a handle on this?
Thanks,
Erik Shreve, PSEM
Software Security Engineer & Architect (CMCU Platform Development)
Texas Instruments