Hi Reinhard,

Guess this diagram for a long time ago design since the latest version there is no need for NS SVC. (Check diagram attached in the ticket).

I think the existing library model implementation is almost the one you described, just some points: - We use a secure SVC in SPM for sanitization input/output buffers. - We do secure partition maintenance in SPM (forward call, maintain state).

The TZ API implementation under SFC is for the purpose that some services have bound the client with policies so they need to know which client is calling. It can be skipped if there is no such client-orient policy.

And one thing to mention, even we propose to use locks in RTOS for locking the interface, there would be a chance that some RTOS has a limitation on these lock APIs, or someone just acts as an attacker who skips the necessary locking operations, then we need to provide some detection in the secure side as countermeasures, and this part needs to be documented to remind users that, please make sure there is only one ongoing secure call or a panic is generated. Then it would be RTOS' choice to decide if they want to avoid this panic by locking.

/Ken

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Reinhard Keil via TF-M Sent: Thursday, December 12, 2019 11:22 PM To: tf-m@lists.trustedfirmware.org Subject: Re: [TF-M] Simplify RTOS / TF-M interface (single thread execution)

As the picture got lost, I did create also https://developer.trustedfirmware.org/T615 This contains the picture

Reinhard

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.