Hi Andrej,
There are already multiple levels of abstraction depending on what the goal is and what requirements are.
From an application point of view, the porting abstraction are the PSA developer API through which services can be called regardless of the underlying infrastructure. TF-M repo contains the API definition and an example implementation for those. From a service developer point of view, existing PSA developer API implementations are a good point of reference on how to interface with different delivery mechanisms for NS-S interaction.
The porting abstraction from a complete non-secure binary/RTOS point of view are the veneers as provided in the object file exported from the secure link stage.
If one wants to provide a NS RTOS port, veneers unrelated to services - i.e. TrustZone functions and client ID registration if applicable - need to be accessed to keep SPM informed. How that access is implemented is very much dependent on the RTOS architecture and the one doing the RTOS port must provide the full "plumbing" up until the call to the veneers, so I am not sure defining an additional abstraction beyond the veneers is feasible. For some mechanisms possibly NSPM checks may also need to be adjusted to cater for the NS RTOS features. See below for more details.
As the solution needs to be tailored to any given RTOS, I cannot provide an implementation suggestion without getting into the internal workings of the specific RTOS. What I may be able to provide instead are the key expectations a particular implementation needs to satisfy. Note that below is only applicable if the RTOS port is expected to provide non-secure client identification when accessing secure assets. 1.1 Non-secure client ID management only provides additional security layering if there are trust boundaries within the non-secure domain and an entity protected from other components has ownership of the non-secure client ids. 1.2 In such a case TF-M trusts the protected entity with non-secure identity management. 1.3 For the sake of clarity: a. The non-secure, unprotected entities would typically be implemented as unprivileged applications/threads/tasks - depending on the terminology of a given RTOS. b. The protected non-secure entity would be privileged code, i.e. an RTOS with privilege management, and its support libraries 1.4 TF-M NSPM must be able to identify that a client ID registration was initiated by the privileged and protected entity
Note that in this case: 2.1 Secure assets may be accessed based on their non-secure client's identity. 2.2 An exploit in one unprivileged application would not cause disclosure of another unprivileged application's assets. 2.3 An exploit in the non-secure privileged code could enable an attacker to gain access to assests owned by an arbitrary non-secure entity, but crucially: 2.4 An exploit in either an unprivileged application or the non-secure privileged code would not expose assets to the attacker that are not available to any non-secure entity.
Hope this provides some more clarity on what is expected of the non-secure binary.
Regards Miklos
-----Original Message----- From: Andrej Butok andrey.butok@nxp.com Sent: 29 July 2019 10:23 To: Miklos Balint Miklos.Balint@arm.com Cc: tf-m@lists.trustedfirmware.org; DeMars, Alan ademars@ti.com; Ken Liu (Arm Technology China) Ken.Liu@arm.com Subject: RE: Non-secure SVC handling
Hi Miklos,
Right, this was about the non-secure SVC. If the NS-SVC was used just as an example, could you suggest other (non-SVC) recommended options to register a client ID? Could it be added as a part of the HAL layer (or other porting abstraction) to make it clear that it is not part of the TFM design?
Thank you, Andrej
-----Original Message----- From: Miklos Balint Miklos.Balint@arm.com Sent: Monday, July 29, 2019 10:06 AM To: Andrej Butok andrey.butok@nxp.com; Ken Liu (Arm Technology China) Ken.Liu@arm.com; DeMars, Alan ademars@ti.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Non-secure SVC handling
[from thread: RE: Adding a platform specific tfm_svc_number_t]
Hi Andrej,
Please note that non-secure SVC handling is independent of secure SVC handling - the two are implemented separately in the code base and hardware resources are banked for their execution. The original discussion is about secure SVC handling type and functions, which are unrelated to NS RTOS dependency on (NS) SVC. I'm starting a separate discussion thread for NS SVC occupancy to avoid blurring the lines between the two.
Please note that any example code in the TF-M repository on NS SVC handling is for demonstration purposes and not, strictly speaking, part of TF-M core implementation. It shows how a non-secure privileged entity needs to register a client ID to the SPM on task creation, if multiple client IDs are managed by the RTOS. Whether a specific implementation uses SVC or another method for running the corresponding privileged code is out of scope of the design, only one possible option is shown, but this is an RTOS-specific problem. Meaning that in an RTOS where the adaptation layer mustn't use SVC and is relying on some other method, there's no design limitation in TF-M that is in conflict with that - the implementation can be adjusted in line with the RTOS's method of choice, but where the NS RTOS has no such restriction, the adaptation layer can rely on SVC for this feature.
Thanks Miklos
-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Andrej Butok via TF-M Sent: 26 July 2019 08:29 To: Ken Liu (Arm Technology China) Ken.Liu@arm.com; DeMars, Alan ademars@ti.com Cc: tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] Adding a platform specific tfm_svc_number_t
Just another use-case, FreeRTOS is using the non-secure SVC. It does not expect that it may be used by somebody else (not RTOS). Ideally, if TFM will not occupy SVC.
-- TF-M mailing list TF-M@lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.trus...