Miklos,

Thank you for those clarifications. Sorry it's taken so long to reply.

I think I now have a basic grasp of how interrupts owned by SPs are managed.

Regarding item 4) below, what is the proposal for informing a calling NS thread that a service request can't complete until some future asynchronous event (ie a peripheral interrupt) occurs? Will this be in the form of special psa_call() return codes or is the SP expected to use outvecs to convey that information? How will the calling thread know when the service request can be completed?

The idea of a dedicated non-secure interrupt that the SP/SPM triggers has been mentioned several times. Some kind of asynchronous callback dispatcher as hinted at in the "Concurrent secure service requests" paragraph here:

https://developer.trustedfirmware.org/w/tf_m/design/ns_client_management/

Is this mechanism being designed by TFM or is this functionality going to be left to the various users of the reference PSA implementation? Should I begin designing this myself?

I guess the overarching question is, does the PSA proposal support secure peripheral drivers, and if so, how?

Alan

-----Original Message----- From: TF-M [mailto:tf-m-bounces@lists.trustedfirmware.org] On Behalf Of Miklos Balint via TF-M Sent: Tuesday, February 05, 2019 8:02 AM To: tf-m@lists.trustedfirmware.org Cc: nd Subject: [EXTERNAL] Re: [TF-M] IRQ handling by Secure Partitions proposal

Hi Alan,

0, One thing to point out is that my proposal only covers the "Library" or function-call-based model that was the only one implemented on TF-M master branch at the time of writing. PSA Firmware Framework v1.0 with its IPC mechanism has its own design of how interrupts are supposed to be handled by secure threads - my proposal intends to complement that with the same functionality for the other operating model. This clarification addresses point 5 as well, I believe.

1, SPM "Acknowledges the interrupt": this is not the best wording. Actually this is very bad wording. What I meant to say is that SPM's own interrupt handler is started - which is a hardware action, not one by SPM - and SPM ISR in turn masks the interrupt line in NVIC. As you rightly point out, the peripheral itself is of no concern to SPM, that's the business for partition code, either in its own Partition ISR, or a service function.

2. This means that secure PSP is saved for the pre-empted context, set to the stack of the partition that's the owner of the interrupt line, and any additional housekeeping associated with a context switch (PSPLIM setup, isolation re-configuration, privilege setting - all according to the properties of the partition that is to be activated). Lastly, a mock context is created on the partition stack so that the Partition ISR can be activated with an exception return from the SPM ISR.

3a. The Partition ISR is activated by SPM ISR by doing an exception return to the start address of e.g. UART1_ISR() function. In order for this TF-M first needs to create the mock context mentioned in my point 2. The discussion of the stack frame in the text is meant to clarify that there are two possibilities that need to be considered: if the partition is idle, i.e. there are no ongoing service requests in its context, its stack pointer is either at a default value or - potentially - there's no stack associated with the partition. In that case a stack frame needs to be initialized and the mock context set up there. If the partition is handling a request, its original stack pointer needs to be used as the start address for the mock context used for exception return. 3b. After execution of the Partition ISR, execution is returned to the SPM ISR. At this point, SPM can decide to either re-activate the original context that had been pre-empted by the interrupt, or, can take a scheduling decision to activate a different context, e.g. the partition that had called psa_wait().

4. The current implementation does not allow for the pre-emption of a secure context by non-secure scheduling events, but that is a limitation that could likely be lifted depending on some basic policies that have to be set up by the system integrator. In such a case the NS thread would be blocked waiting on the completion of the secure service, but a pre-emptive NS OS could schedule a different thread if the time slice of the caller thread runs out. Other options are subject to investigation at this point.

...

Please let me know if any of the points I've addressed provide clarity instead of making the design more obscure, in which case I would update the design proposal with the extra information. :) And of course let me know if you have further questions.

Regards Miklos

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of DeMars, Alan via TF-M Sent: 02 February 2019 04:29 To: tf-m@lists.trustedfirmware.org Subject: [Tf-m] IRQ handling by Secure Partitions proposal

Regarding the "SPM behavior" discussion in the "Secure Partition Interrupt Handling" proposal:

1) What is meant by the SPM "Acknowledges the interrupt"? I understand "masks the hardware interrupt line" but I don't see how the SPM can know how to acknowledge a particular peripheral's interrupt. I think acknowledging the interrupt should be done by the "Partition ISR" dedicated to the interrupt, or within the corresponding SP's main loop upon return from psa_wait().

2) What does "Sets up execution environment for the secure partition" mean, precisely?

3) Can you expand on the "Execute Partition ISR" paragraph a little? I assume you mean that, for instance, the registered UART1_isr() function is called. The discussion of the ISR stack frame I don't really follow. And from the description, I'm not sure when the SP is scheduled to run again to deal with the ISR it was waiting for.

4) A secure partition that depends on an interrupt begs the question of what happens to the NS thread that has called into the SP requesting some service that depends on a subsequent asynchronous event (ISR) to complete the request. The psa_call() function as currently implemented doesn't "block" in the traditional OS sense (ie the thread's context and state are not saved in a manner that allows another task thread to run while the psa_call() is stalled in the SPM waiting for an ISR.

5) The details of SP thread pre-emption and re-entrancy need to be described.

Alan