Is pre-emption while in secure mode supported? If so, NS RTOS may have to be modified to handle switching from a thread who's PC and SP are in secure domain.
How would a secure service thread block while waiting for a security-protected hardware process to finish (ie what is the secure driver model)?
Alan
From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Reinhard Keil via TF-M Sent: Thursday, April 2, 2020 5:49 AM To: tf-m@lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] [TF-M] Multi-threaded single-scheduler model proposal
Hi Erik,
Really great to see your involvement. Let me share my view on a TF-M execution model for constrained single core v8-M with TrustZone using Secure Function Call (aka library) mode:
On secure side: single thread execution only. Not stack swapping. NS to S calls are blocking until secure execution completes. On non-secure side: RTOS with threaded execution. Entry to secure side protected with Mutex.
This structure is explain on page 27 of https://github.com/ARM-software/CMSIS_5/blob/develop/CMSIS_Review_Meeting_20...
IMHO, there are various benefits: * Overall less complexity, no need of tz_context, any RTOS would work, less memory overhead (i.e. single stack at secure side) * No impact to time deterministic execution on the NS side unless two threads call secure services * Conflict of mulitple threads calling secure services could be minimized with RTOS that offers priority inversion
Are there any obvious problems with the above model?
Thanks Reinhard Keil - Sr. Director Embedded Tools, Arm
P.S. maybe you read also https://lists.trustedfirmware.org/pipermail/tf-m/2020-March/000805.html IMHO we need to simplify the NS to S call entry to speed-up the overall system
Alan,
Yes, pre-emption must be supported otherwise time deterministic execution on non-secure side would be impossible.
A fundamental attribute of v8-M is interrupt execution in NS while S thread execution. Interrupts are not blocked (provided that priorities are selected correctly).
Pre-emption in an Cortex-M RTOS works typically with the PendSV interrupt. Important is that PendSV interrupt on NS is not blocked by secure execution. This should already ensure that an RTOS can schedule execution back to NS while anther NS thread is currently execute a secure service.
Reinhard
When the secure service starts a hardware process (ie crypto accelerator), how does it then block, allowing other NS threads to run while waiting for the hardware process to finish as signaled by a secure interrupt? And then, how does that secure interrupt unblock the thread waiting for it so that the secure service request can complete?
Alan
From: Reinhard Keil [mailto:Reinhard.Keil@arm.com] Sent: Thursday, April 2, 2020 6:22 AM To: DeMars, Alan; tf-m@lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] RE: [TF-M] Multi-threaded single-scheduler model proposal
Alan,
Yes, pre-emption must be supported otherwise time deterministic execution on non-secure side would be impossible.
A fundamental attribute of v8-M is interrupt execution in NS while S thread execution. Interrupts are not blocked (provided that priorities are selected correctly).
Pre-emption in an Cortex-M RTOS works typically with the PendSV interrupt. Important is that PendSV interrupt on NS is not blocked by secure execution. This should already ensure that an RTOS can schedule execution back to NS while anther NS thread is currently execute a secure service.
Reinhard
Alan,
The un-interrupted execution flow in such scenarios should look like:
1. NS thread calls secure service, S execution in thread mode 2. S execution triggers crypto hardware accelerator then executes WFE (wait for interrupts, but still is in thread mode) 3. crypto hardware raises IRQ, interrupt execution in secure mode 4. After interrupt execution, return to secure thread mode 5. When secure service completes return to NS thread mode
The only time where NS interrupts are effectively blocked are during (3) interrupt execution in secure mode. Important is to keep this interrupts short. During (1), (2), (4), (5) RTOS pre-emption is not blocked.
Is this in-line with your thinking?
Reinhard
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.
Alan
From: Reinhard Keil [mailto:Reinhard.Keil@arm.com] Sent: Thursday, April 2, 2020 6:39 AM To: DeMars, Alan; tf-m@lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] RE: [TF-M] Multi-threaded single-scheduler model proposal
Alan,
The un-interrupted execution flow in such scenarios should look like:
1. NS thread calls secure service, S execution in thread mode 2. S execution triggers crypto hardware accelerator then executes WFE (wait for interrupts, but still is in thread mode) 3. crypto hardware raises IRQ, interrupt execution in secure mode 4. After interrupt execution, return to secure thread mode 5. When secure service completes return to NS thread mode
The only time where NS interrupts are effectively blocked are during (3) interrupt execution in secure mode. Important is to keep this interrupts short. During (1), (2), (4), (5) RTOS pre-emption is not blocked.
Is this in-line with your thinking?
Reinhard
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
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
tf-m@lists.trustedfirmware.org
-
DeMars, Alan -
Reinhard Keil