Hi,
I am using an MCU with cortex-m33 processor and my project demands to put the entire FreeRTOS OS in secure side of trustzone(with task running in secure and non-secure side).
I want to configure the secure FreeRTOS scheduler to schedule the secure and non-secure tasks.
But as per FreeRTOS kernel, trustzone can not be enable while running FreeRTOS in secure side.
/* Set to 1 when running FreeRTOS on the secure side. Note that in this case TrustZone is
* not supported as secure tasks cannot call non-secure code i.e. configENABLE_TRUSTZONE
* must be set to 0 when setting configRUN_FREERTOS_SECURE_ONLY to 1. */
#define configRUN_FREERTOS_SECURE_ONLY 1
However there are many reference i found for different MCU which mention a algo to customize the FreeRTOS kernel to run the FreeRTOS from secure side with trustzone enable and with secure and non-secure tasks running.
I want to know why FreeRTOS kernel restrict to disable the trustzone while running FreeRTOS in secure side?
Is there any way to run the FreeRTOS scheduler in secure side and tasks in secure and non-secure side without patching in kernel code?
Per ARM’s recommendation, in ARMv8-M, secure side is supposed to contain minimal security related code and everything else including RTOS is supposed to run on the non-secure side. Therefore, this design choice is in-line with ARM’s recommendation. Can you share the links you are talking about? Also, can you provide more details about what security threat are you trying to address? Happy to hop on a call if you think that can help.
Thanks Gaurav for your quick response.
My project required to divide the entire software into two parts-
First part shall contain the [core functionality(mostly data acquisition from external devices)] + [System level components (OS+SDK)]
And second part contains the application logic written around the acquired data.
and we just want to expose the limited interface API and limited data to 2nd part of the code.
And to achieve this restriction we decide to declare the first part as secure and 2nd as non-secure.
Links that claim RTOS in secure side
This NXP’s application note claims that the FreeRTOS scheduler can be run in secure side and task can be place in both secure and non-secure side -
[ Section 4.2 of AN13094.pdf (sorry i am not allow to put the link here, please google this doc)]
i would be happy to share the reference document mentioned in this application note that contains a algo to schedule the secure and non-secure tasks from secure freeRTOS kernel.
The following discussion also result in running scheduler in secure side-
Arm Community post - how-to-place-freertos-in-secure-memory-and-the-user-tasks-in-non-secure-memory ( again sorry i am not allow to put the link here )
Finally, I agree that as per ARM’s recommendation, in ARMv8-M, secure side is supposed to contain minimal security related code and everything else including RTOS is supposed to run on the non-secure side.
But it is recommendation from ARM not the restriction but as per FreeRTOS it looks like a restriction that the OS shall always be in non-secure side if trust zone is enable.
Is there any plan by FreeRTOS to allow the user to chose which side suited best for OS as per the application.
Secure code can call unsecure functions, so as long as you get the function pointers “somehow” into your secure projects you can easily have secure threads which use unsecure functions, e.g. call application task handlers (not the FreeRTOS tasks themselves).
FreeRTOS would be unaware of the trustzone in that constellation though.
If FreeRTOS scheduler is unaware of trustzone, How would FreeRTOS switch MCU registers (example - between S_PSP and NS_PSP,) between secure and non-secure handlers if preempt in between?
[edit] the comment about about using the secure side stack below not correct [/edit]
If you had the address of the non secure function it may be possible to call it, not sure as I’ve never looked into it. If you did it would have to use the secure side stack. The opposite is definitely not true - a non secure function can’t call a secure function just by knowing it’s address.