Hi Erik,

Right, I had in mind the next forum on Apr 2, which is planned for US time zone. Invitations will be send soon having no more ideas or objection on the time slot.

The forum format is open and quite unformal. You can find the recordings of all sessions here: https://www.trustedfirmware.org/meetings/tf-m-technical-forum/ I would suggest to have few slides with the concept for idea introduction and references during discussion.

All the best, Anton Komlev

From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Shreve, Erik via TF-M Sent: 23 March 2020 21:26 To: tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: Re: [TF-M] Multi-threaded single-scheduler model proposal

Anton,

Yes, I can be prepared to discuss in the next forum. (I believe you are referring to the one on April 2nd). I've not participated in the forums yet, please send me some information as to the format/rules/etc.

Thanks!

Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development)

From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Anton Komlev via TF-M Sent: Monday, March 23, 2020 3:39 PM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] Multi-threaded single-scheduler model proposal

Hi Erik,

Thanks for proposing improvements to TF-M, cooperative scheduling namely. You hit the topic which was considered but postponed at some moment. Believe, it will be beneficial to all of us to discuss it online and share our views on potential improvement and possible side effects.

Let me know, please, if you want to include this topic into next forum agenda?

Kind regards, Anton Komlev

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: 23 March 2020 14:26 To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Subject: [TF-M] Multi-threaded single-scheduler model proposal

I'd like to propose an additional model that provides a single-scheduler _and_ multiple thread support for PSA RoT. To state a little more specifically: * The NSPE scheduler makes all scheduling decisions for execution (call) flows of the NSPE tasks - including when those flows are operating in secure side * APIs are provided to the NSPE scheduler to switch SPE task contexts (one task context associated to each NSPE task that uses PSA RoT) * Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) * A SPE scheduler may still exist for application root of trust services, if any exist on a system.

I don't see anything written up on a model like this in the design proposals or Phabricator. However, it appears to me that such a model (or something similar) must have been previously discussed.

1. There already exists a tz_context API set in CMSIS-Core for communicating task switches by the NSPE scheduler to the SPM 2. Cooperative scheduling rules design was accepted: https://ci.trustedfirmware.org/job/tf-m-build-test-nightly/lastSuccessfulBui... 3. https://youtu.be/6wEFoq49qUw?t=1671 speaks about having a stack on the SPE per NSPE task. Also, the question from the audience at the end of the presentation relates to having a single NSPE scheduler.

A brief word on the motivation for such a proposal... To ease (and thus increase) adaptation of PSA RoT, wherein those services are protected from nontrusted code, the impact to the NSPE code should be minimized. The current models (Library, IPC) do well to minimize the impact from an API standpoint. That is, the NSPE caller need not know where/how the PSA RoT operates in order to compile. However, the current models do not minimize impact to scheduling on single core systems. The library model locks behind a single mutex the operations that previously existed independent of one another. The IPC model provides more flexibility. However, it still extends lock times beyond current implementations and it introduces an additional scheduler which removes determinism and forces system designers to rethink existing code.

I'd like to know if there are any recorded plans for such a model (or something more similar to it than the three items above). If not, has it been discussed and actively rejected? If so why?

I can/will write up a more concrete proposal, but wanted to get some discussion around the high-level idea first.

Thanks,

Erik Shreve, PSEM Software Security Engineer & Architect (CMCU Platform Development)

Texas Instruments Inc. 12500 TI Boulevard, MS F4000 Dallas, TX 75243