Hi Ken,
Thanks for feedback.
TFM_NS_CLIENT_IDENTIFICATION is based on https://arm-software.github.io/CMSIS_5/Core/html/group__context__trustzone__...
The CMSIS documentation is misleading and I can see why you think it is easy to manage secure storage using the same interface. RTOS Thread Context Managementhttps://arm-software.github.io/CMSIS_5/Core/html/using_TrustZone_pg.html#RTOS_TrustZone relates as the name indicates to specific threads. It is used to manage the secure stack space for NS->S function calls that are directly initiated by a thread.
When the same mechanism is used to protect permanent storage, it implies that this storage is always accessed by the same thread. However user applications may create/destroy threads (run a different combination of threads) which would break this protection already during run time. Moreover when you update your firmware image on the secure side, the thread IDs (module ID) are likely to change, hence a new firmware version might be unable to retrieve information that was stored by a previous version.
Long story short:
* I cannot see that TFM_NS_CLIENT_IDENTIFICATION gives us a solution that works in partice. * I will request to fix the CMSIS documentation for "Thread Context Management"; make it clear that is about thread execution.
In a nutshell: we should consider to remove TFM_NS_CLIENT_IDENTIFICATION as I cannot see that it works.
Reinhard
tf-m@lists.trustedfirmware.org