SST: Use get caller client ID API in SST
This change modifies SST service to use
tfm_core_get_caller_client_id(...), provided by the TF-M core, instead
of use the client ID provided by the dummy ID manager via the SST APIs.
The details of this change are:
- Remove client_id from the veneer API of SST (except for the read
operation, as referenced read is still possible)
- Remove the dummy ID manager
- Add documentation on how to integrate this new method to a NS
application
- Change Asset management to work with non-hardcoded secure
client ID
Change-Id: Ic97ea7aa5840d7e212adc009fa39c1c505440965
Signed-off-by: Mate Toth-Pal <mate.toth-pal@arm.com>
diff --git a/docs/user_guides/tfm_ns_client_identification.md b/docs/user_guides/tfm_ns_client_identification.md
new file mode 100644
index 0000000..21eba4d
--- /dev/null
+++ b/docs/user_guides/tfm_ns_client_identification.md
@@ -0,0 +1,42 @@
+# Non-Secure Identity Manager
+
+The ID of the current application/thread is known by TF-M, and the SST service
+queries the ID of the currently running client via a dedicated API.
+
+The identity of secure clients can be tracked by TF-M core, because it also
+manages the contexts of the partitions. However to differentiate NS clients, it
+relies on the services provided by the NS OS.
+
+Tracking of context changes are possible by relying on the NS OS calling the
+Thread Context Management for Armv8-M TrustZone APIs, as described
+[here](https://www.keil.com/pack/doc/CMSIS/Core/html/group__context__trustzone__functions.html)
+
+However TF-M needs an extra API, to assign a client ID to the TZ context created
+as a result of the
+`TZ_MemoryId_t TZ_AllocModuleContext_S (TZ_ModuleId_t module)` call.
+
+To do this, the
+`enum tfm_status_e tfm_register_client_id (int32_t ns_client_id)` have to be
+called from an SVC handler, with the client ID of the currently running client.
+
+In the current implementation of TF-M, an SVC call is provided for the NS
+clients to be called at the beginning of their main function.
+
+```SVC(SVC_TFM_NSPM_REGISTER_CLIENT_ID);```
+
+The SVC call handler of the above SVC maps the name of the current thread to a
+hardcoded client id, and sends it to the TF-M core via the earlier discussed
+API.
+
+The mapping is implemented in `interface/src/tfm_nspm_svc_handler.c`.
+
+The system integrators **may** implement the non-secure ID mapping based on
+their application/threat model.
+
+In case the NS OS doesn't use the Thread Context Management for Armv8-M TrustZone
+APIs, then TF-M considers the NS SW as a single client, and assigns a client ID
+to it automatically.
+
+--------------
+
+*Copyright (c) 2018, Arm Limited. All rights reserved.*