Non-secure client identity API for secure services
Closed, ResolvedPublic


While ARMv8M architecture allows calling a secure function from non-secure code both in thread mode and handler mode, there are benefits to requiring certain types of secure functions to be called exclusively from either one or the other.
In the current trusted-firmware-m implementation handler mode calls are enforced by the framework for all secure service accesses so that the non-secure privileged code that has ownership of the SVC handler can provide access control to secure resources for non-secure threads, associate an identity with each caller thread and/or perform any other administrative tasks associated with a function call.
Similarly, upon entering the secure veneer, tfm_core_sfn_request_function() is run in privileged mode to prepare the execution context for the secure function and potentially perform sanitization of its input parameters.

Task description and rationale:
Creation of the secure context for the execution of the secure service is easier if secure service calls from NS clients are only permitted to be called from NS thread mode, while NS handler mode secure calls are reserved for NS RTOS to TFM Core interactions where elevated privilege of the NS caller is a requirement to get reliable information, e.g. in the case of NS caller thread identification.
If non-secure threads are directly calling secure veneers without going through NS handler mode, TF-M Core needs to be aware of the currently active NS context if multiple NS contexts are allowed to co-exist and their identity needs to be established for secure service access.
TrustZone provides RTOS thread context management functions. Implement the functions specified in TZ context management, tailored to TF-M implementation, to provide an active secure service with (non-secure) client identity information if needed.