Hi,

So you are running an RTOS plus a secure library, and you want to notify the NSPE that a secure interrupt is under handling. This behavior (Calling NSPE function) is not applicable, just as both the post and your reply mentioned. You don’t need to do this, because:

- Secure interrupt priority is boosted, so it is expected that secure interrupt can preempt NSPE execution. Since secure ISR execution is expected so it does not need to yield. - Secure interrupt handling (The ISR) is expected to be very quick and no affecting preempted NSPE execution. This is to ensure the real-time characteristics. - If long time execution is required in secure ISR, using other method for this scenario, such as threaded ISR.

If you insist to notify NSPE, yes, using NS interrupt is more proper, but you need to make sure the tail-chain sequence and make sure it runs as expected.

TF-M prohibits calling back to NSPE during ISR. And it uses a threaded mechanism (SIGNAL notification to owner) for the long time interrupt handling case.

BR

/Ken

-----Original Message----- From: Jan Hoogerbrugge jan.hoogerbrugge@gmail.com Sent: Wednesday, August 4, 2021 4:36 AM To: Ken Liu Ken.Liu@arm.com Cc: tf-m@lists.trustedfirmware.org; nd nd@arm.com Subject: Re: [TF-M] Calling an NSPE function from a secure partition

Hi,

I am calling osSemaphoreAcquire from SPE and osSemaphoreRelease from a SPE ISR. It seems to work via the CMSE.

One thing that worries me is the problem that I had earlier without TF-M. See this posting: https://forums.freertos.org/t/synchonisation-in-trustzone-secure-world-by-ca.... FreeRTOS disabled interrupts before entering a critical section and then an interrupt in secure world occurs that makes a call to FreeRTOS via CMSE while the critical section is busy. The call to FreeRTOS causes a second thread to enter the critical section which causes data structure corruption. Can something similar happen with RTX? If so, should I then solve it in the same way as proposed in the FreeRTOS forum thread by posting a non-secure interrupt?

Jan.

On Mon, Aug 2, 2021 at 10:47 AM Ken Liu via TF-M tf-m@lists.trustedfirmware.org wrote:

Hi Jan,

This behavior is not encouraged in TF-M, as Firmware Framework does not allow such an scenario.

But if you are working on a simple secure library with Trustzone-M you can try to use CMSE API to do that.

Please tell us more details if you are using TF-M, sounds like you are trying to avoid blocking in the SPE.

Thanks.

/Ken

-----Original Message----- From: TF-M tf-m-bounces@lists.trustedfirmware.org On Behalf Of Jan Hoogerbrugge via TF-M Sent: Thursday, July 29, 2021 2:07 PM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] Calling an NSPE function from a secure partition

Hi,

Is it possible/allowed to call a function in NSPE from a secure partition using the GCC Cortex M Security Extensions (CMSE)? If NSPE and SPE are on different cores then it is definitely not working but in my case they are on the same M33 core.

If it is possible then I would like to call a semaphore P operation in the RTOS that might block. Will that work?

Regards, Jan. -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m -- TF-M mailing list TF-M@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-m