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