Hi Reinhard,
My assumption on the user side: - For application developers, they don't need to care about the identification and just access secure service via API. - For non-secure OS (or, a whole system level including SPE and NSPE) developers or integrators, they can implement a mechanism to help SPM identify the different non-secure threads, then SPM can do more granular client management (access control or other policies). If the don't, then SPM take whole NSPE shares the same non-secure client id and no more granular client management.
Still need the real USER to provide more information in case my assumption covers partial scenarios only.
Thanks.
/Ken
From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Reinhard Keil via TF-M Sent: Tuesday, April 28, 2020 2:57 PM To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [TF-M] Questions on TFM_NS_CLIENT_IDENTIFICATION
I see that there has been some progress in the source code to further remove the overhead of TFM_NS_CLIENT_IDENTIFICATION when the option is disabled.
However, I still don't understand the user view of that feature. How should I use it, also considering the fact that my application may get updated during lifetime.
Reinhard