this text
"
However, with the guidance from PSA & Trusted Firmware team, the plan for FreeRTOS port is to have the OS running in Non-secure world, and OS helper APIs in Secure world to help context switching.
"
And get impression that it is only one reasonable configuration for OS location for be sure that maximum code should be executed with minimal privileges and on only really trusted software should be on Secure side.
The official FreeRTOS ARMv8-M port allows you to run the kernel on the non secure side and create both secure and non secure tasks. Floating point, memory protection and trust zone are all compile time options. Alternatively you can run the kernel on the secure side, but when you do that you cannot create non secure tasks.
It would help us greatly if you could describe your use case as it helps us plan our own roadmp. Which configuration do you want, and why is it necessary?
I think non secure side RTOS is not able to have full secure side tasks in current implementation.
ISR from secure side can’t send message to queue and receive it on secure side. ISR should make nonsecure side call and from it context send message to queue on non secure side.
Only NSC like calls e.g functions what is not able to utilize RTOS objects directly.
In our case we have typical IOT device where one task with user privilege talk to external world. But it is also exists few sensors what would be nice to hide on Secure side for avoid any posibility to have some impact from communication task on non secure side.
But what is not clear if it have some advantages if data from the same sensor is processed on nonsecure side in other non privileged tasks. Distance between secure and nonsecure side looks 2x time “longer” than between 2 tasks with user privileges.
May be better to have RTOS on secure side and allocate only communication task on non secure side.
And this dilemma not have direct answer.
Is this so ?
Normally we would advise to keep the minimum possible on the secure side. If you have a sensor reading that must be authenticated to be trusted you can read the sensor on the secure side, sign the value and if necessary encrypt the value, and then pass it to the non secure side for transmission onto the network. The receiver can then validate the signature to ensure nothing on the on secure side or on the network tampered with the value…I suspect this is overkill for your use case though.
Yes, reading of sensor on secure side ( i2C interface for example ) require processing of ISR on secure side and at the end of transaction signal to nonsecure side semaphore and secure ISR should callback to nonsecure side in handler context and release semaphore from there.
This scheme works for sure but do full processing on secure side e.g full secure side task with native utilizations of RTOS objects looks as native solution.
If nonsecure OS can have secure task, configuration of it should have MPU tables as well.
And it means that whole secure side should have active MPU. The same assumption is valid vice versa. As result it have sense to have RTOS on one side but tasks can be allocated at any side and MPU should be active on both sides.
But may be nonsecure RTOS with secure calls is looks as practical approach what is good enough for 99% of solutions.
Can you share typical way of Secure MPU usage with FreeRTOS ?
Does it it hardcoded configuration ? Or dynamic MPU tables activated together with Secure Context activation or they attached to some API calls ?
What way of usage was found as one what is light and what increase security level ?
Have it sense to add it as one of possible RTOS configuration ?
The devices are very new so ‘typical’ use is limited to a small set of users at the moment - but in most cases what we see and general advice is to keep the code on the secure side to a minimum so it can be developed to a very high standard and still remain ‘trusted’. Again ‘typically’ keeping to a minimum means using the secure side as the root of trust for things like hand over from a secure bootloader to set up mpu/sau once the signature of the application image has been verified, secrets management (keys, etc), crypto operations, etc. Additionally application code that does things such as read a pin code from a keypad is placed on the secure side too, but isolated from the root of trust code using the MPU. In most cases where users have talked with us about placing code on the secure side for doing things like isolating third party code they are actually better off just using the memory protection unit on the non secure side for the same purpose.
Most probably they use static MPU configuration what is applied at early boot time.
If Tasks with user privileges is used on non secure side, NSC calls also appears with nonprivileged rights on secure side.
ARM here : https://community.arm.com/cfs-file/__key/telligent-evolution-components-attachments/01-2142-00-00-00-00-69-67/Session-6-2D00-Yiu-2D00-The-Next-Steps-in-the-Evolution-of-Embedded-Proc.pdf
on Figure 9. promote special manager what analyze NSC calls and configure MPU on fly.
I just wondering if in current RTOS configuration it is easy to add secure MPU tables at task creation point and when task jump to Secure side, there are automatically activated ?
But Secure MPU tables might be build dynamically and actual addresses might be known on secure side only and nonsecure side should know about those some how.