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/services/tfm_sst_integration_guide.md b/docs/user_guides/services/tfm_sst_integration_guide.md
index ee26c05..d808778 100644
--- a/docs/user_guides/services/tfm_sst_integration_guide.md
+++ b/docs/user_guides/services/tfm_sst_integration_guide.md
@@ -366,19 +366,17 @@
}};
```
-### Non-Secure Identity Manager
+### Client Identification
-The SST service requires, from the non-secure side, a mechanism to retrieve
-a numerical ID associated to the running application/thread which performs
-the call to the SST service. That identifier is the one used to validate the
-access permissions against the requested asset.
-For API specification, please check:
-`interface/include/tfm_id_mngr.h`
+TF-M core tracks the current client IDs running in the secure or non-secure
+processing environment. It provides a dedicated API to retrieve the client ID
+which performs the service request.
-A stub implementation is provided in `interface/src/tfm_id_mngr_dummy.c`
+[ns client identification documentation](../tfm_ns_client_identification.md)
+provides further details on how client identification works.
-The system integrators **must** implement the non-secure ID manager based on
-their application/threat model.
+SST service uses that TF-M core API to retrieve the client ID and validate the
+access permission against the requested asset.
The [integration guide](../tfm_integration_guide.md) provides further
details of non-secure implementation requirements for TF-M.
diff --git a/docs/user_guides/tfm_integration_guide.md b/docs/user_guides/tfm_integration_guide.md
index 93182eb..895bb34 100755
--- a/docs/user_guides/tfm_integration_guide.md
+++ b/docs/user_guides/tfm_integration_guide.md
@@ -67,15 +67,11 @@
a collection of functions in the `<build_dir>/install/export/tfm/inc`
directory. For example, the interface for the Secure STorage (SST) service
is described in the file `psa_sst_api.h` as a collection of
-functions that call service veneer functions. The services can be called from the
-non-secure world applications (running in Thread mode) using the wrapper API
-which is described in `psa_sst_api.h`. This API is a wrapper for the secure
-veneers, and returns the return value from the service to the caller.
-The secure storage service also needs the NS side to provide an implementation
-for the function `tfm_sst_get_cur_id()` which is used to retrieve the numerical
-ID associated to the running thread. A primitive implementation is
-provided in `tfm_sst_id_mngr_dummy.c`. It is system integrators responsibility
-to implement the SST ID manager based on their threat model.
+functions that call service veneer functions. This API is a wrapper for the
+secure veneers, and returns the return value from the service to the caller.
+The secure storage service uses a numerical ID, to identify the clients that use
+the service. For details see
+[ns client identification documentation](tfm_ns_client_identification.md).
#### interface with non-secure world regression tests
A non-secure application that wants to run the non-secure regression tests
@@ -93,6 +89,9 @@
needs to provide the implementation of these wrappers to be able to run the
tests.
+#### NS client Identification
+See [ns client identification documentation](tfm_ns_client_identification.md).
+
--------------
*Copyright (c) 2017-2018, Arm Limited. All rights reserved.*
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.*