Erik, Alan,

Sorry I had not enough time to participate the whole meeting yesterday and I therefore kicked-off some discussion before.

It’s really great to see your engagement here.

Let me summarize:

TF-M should work with many different RTOSes as the various CSPs currently have preferences (Azure=ThreadX, AWS=FreeRTOS, etc.).  To make it easy to work with this diverse eco-system we should aim for simplicity of TF-M/RTOS interaction. Also tz_context slows down overall thread switching and is tricky to use.

I agree with you that we will need a middle ground.  You say:

“No impact to time deterministic execution on the NS side unless two threads call secure services” is the issue.

However I cannot see today an elegant solution.

My question is: what use-cases do you see where two different threads need to call secure services.  Is in such use-cases timing a critical factor?

Alan raised “In a real world use case we are faced with, the process kicked off by the secure service may take a long time (ie several ms)”. This is correct, but makes it really sense to schedule CPU execution. HW accelerator math operations take some ~1usec; thread scheduling is not economic.  IMHO: It is not different from today’s implementation where i.e. mbedTLS is running in a thread. 

For time critical applications you would solve that problem with thread priorities where:

• Crypto is in “Normal” priority
• Time critical execution is “High” priority

I believe we should focus first on a minimum viable product and then analyze the real-world problems that come with it. Maybe there are other solutions that extending the RTOS kernel. 

Have a good weekend.
Reinhard

From: Shreve, Erik <e-shreve@ti.com>
Sent: Thursday, April 2, 2020 4:55 PM
To: DeMars, Alan <ademars@ti.com>; Reinhard Keil <Reinhard.Keil@arm.com>; tf-m@lists.trustedfirmware.org
Cc: nd <nd@arm.com>
Subject: RE: [TF-M] Multi-threaded single-scheduler model proposal

I see the discussion of today’s tech forum agenda has begun ahead of time. J

Individual public key operations can take ms even when accelerated with HW. Further, the HW accelerators operate as math coprocessors with a series of math operations stitched together by SW.

No doubt existing models in TF-M have the benefit of simplicity for the secure code analysis. However, their simplicity complicates the scheduling of the non-trusted code.

The qualifier in this statement “No impact to time deterministic execution on the NS side unless two threads call secure services” is the issue.

I believe we need a middle ground to drive additional adoption.

Erik Shreve, PSEM

Software Security Engineer & Architect (CMCU Platform Development)

From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of DeMars, Alan via TF-M
Sent: Thursday, April 02, 2020 9:47 AM
To: Reinhard Keil; tf-m@lists.trustedfirmware.org
Cc: nd
Subject: [EXTERNAL] Re: [TF-M] Multi-threaded single-scheduler model proposal

I used crypto accelerator as a hypothetical example.

In a real world use case we are faced with, the process kicked off by the secure service may take a long time (ie several ms).

It is not acceptable to be parked in wfe during that time.

Alan

From: Reinhard Keil [mailto:Reinhard.Keil@arm.com]
Sent: Thursday, April 2, 2020 6:52 AM
To: DeMars, Alan; tf-m@lists.trustedfirmware.org
Cc: nd
Subject: [EXTERNAL] RE: [TF-M] Multi-threaded single-scheduler model proposal

Alan,

“I was afraid that this was the proposal. No lower priority NS threads can run while waiting for the secure interrupt. Only higher priority threads that are initiated by a NS interrupt can run.”

You are correct, scheduling of lower priority NS threads would be not possible.  This is definitely a shortcoming of the solution.

May I ask:  how long does a hardware crypto operation take?  What time could be used for low priority NS thread execution?

Reinhard