Hi Erik,

Thanks for your detail explanation and looking forward to your talk. Looks like my assumption was not correct - I had thought you may propose something like thread-mode-scheduling.

/Ken

From: Shreve, Erik e-shreve@ti.com Sent: Friday, March 27, 2020 5:11 AM To: Ken Liu Ken.Liu@arm.com; tf-m@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: RE: Multi-threaded single-scheduler model proposal

Ken,

Thanks for the feedback! I agree that care will be needed in the design and implementation of the calls from S to NS. I hope to provide design details that minimize the risk by minimizing the RTOS specific layer.

Unfortunately, I'm not clear on your feedback about the 'scheduler' and 'context-switch' terms. Let me expand on my proposal here a bit more. Perhaps this will clarify things or at least provide enough detail for you to provide more specific feedback.

I'm sure you are aware that the PSA Firmware Framework provides for the scheduling of the secure partitions. I'm proposing (as an option, it is not a core feature of the proposal) that the SPM may be responsible for scheduling of Application Root of Trust services in this new model. Further, execution of PSA RoT services on behalf of Application RoT services may also fall under the SPM's scheduling. Thus, this part of the new model would fit with the PSA FF spec. This would thus mean that the NSPE RTOS is only scheduling NSPE Tasks and the associated PSA RoT service requests for those NSPE Tasks.

However, supporting the "App RoT scheduling by SPM" in the model may complicate the implementation or at the very least the straightforward understanding of how the model works. The alternative, of course, is that the NSPE RTOS schedules the execution of the Application RoT services the same as it schedules the PSA RoT services. I think I prefer the latter, but I'm open to the former if the community has good reasons for it. One reason might be an expectation that PSA RoT services will be maintained by platform owners and platform owners can choose which models to support, but the community may want creators of Application RoT services to have the same experience regardless of the model implemented.

Thanks!

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

From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Ken Liu via TF-M Sent: Monday, March 23, 2020 9:49 PM To: 'tf-m@lists.trustedfirmware.org' Cc: nd Subject: [EXTERNAL] Re: [TF-M] Multi-threaded single-scheduler model proposal

Hi Erik,

This is a good proposal, thanks.

And I got two comments in your listed bullets:

* Resource locking APIs are provided to allow PSA RoT functions to communicate with the NSPE scheduler (i.e. mutex take/give) - Even the Trustzone-M supports S to NS call, be cation when you are designing such features because leave a waiting pattern in the secure side exposes one extra interface.

* A SPE scheduler may still exist for application root of trust services, if any exist on a system. - Please use the 'scheduler' and 'context-switch' with scope. If there are 2 threads only and just switching contexts between them, the word 'scheduler' would be a bit confusing here. Hope my assumption is incorrect.

Please go ahead with your preparation for the Tech Forum. Anton can give you detail descriptions about it and I think preparing a PUBLIC slide can be the first step.

Thanks.

/Ken

From: TF-M <tf-m-bounces@lists.trustedfirmware.orgmailto:tf-m-bounces@lists.trustedfirmware.org> On Behalf Of Shreve, Erik via TF-M Sent: Tuesday, March 24, 2020 5:26 AM To: tf-m@lists.trustedfirmware.orgmailto:tf-m@lists.trustedfirmware.org Cc: nd <nd@arm.commailto: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