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