Hi Alan, From my point of view, TZ_StoreContext_S() indicates the non-secure thread accesses secure service is getting switching out, no one should access secure services before a calling of TZ_LoadContext_S(). This case could be covered in below condition in PSA FF client APIs (Picked on line from page 49 of PSA FF 1.0 beta0):
"Calling psa_connect() is a fatal error and will not return if any of the following conditions are met: * ... * The caller is not authorized to access the RoT Service, see RoT Service access control on page 28. * ..."
Pining the calling non-secure thread is the proper way - which means, 'Does not return' to the non-secure thread in this case.
There should be no such an API to peek the status of SPM from caller out of SPM. And there should be a similar API for SPM (only) to retrieve the current MemoryID (or information could be represented as MemoryID).
BR
-Ken
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of DeMars, Alan via TF-M Sent: Thursday, February 21, 2019 10:54 PM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] What is the behavior of SPM between `TZ_StoreContext_S()` and `TZ_LoadContext_S()`
Are calls to psa_connect/call/close allowed after `TZ_StoreContext_S()` has been called but before `TZ_LoadContext_S()` is called? If not, does that result in a panic or simply error return codes?
Is there a secure-side SPM API that can be invoked from a custom veneer function to determine if the SPM is in the zone between `TZ_StoreContext_S()` and `TZ_LoadContext_S()`?
Is there an API that returns the current MemoryId?
Alan
TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m