portSVC_RAISE_PRIVILEGE behaves differently in mpu wrapper v1 and v2

Kernel
1

Hi Guys

I recently worked on a project integrating MPU on Cortex-M4.

I notice that in freeRTOS 10.5.1 with mpu wrapper v1, I could use portSVC_RAISE_PRIVILEGE() to enter privileged mode inside application code.

However, the same code didn’t work when upgrading to freeRTOS 11.1.0 with mpu wrapper v2. I confirmed that I have configured in the FreeRTOSConfig.h to use mpu wrapper v2.

And then I checked the code and seems portSVC_RAISE_PRIVILEGE is only supported when using mpu wrapper v1.

My question is for v2, how to let application functions access system core registers like SCB and NVIC without using portSVC_RAISE_PRIVILEGE ?

I have tried using portPRIVILEGE_BIT and made my application tasks run in privileged mode and it worked. I am wondering if there is any other solutions.

Thanks in advance.

2

Hi @pasu
In the current FreeRTOS Kernel (v10.6.2 + ) , MPU wrappers were updated to address security concerns. As a result, an unprivileged task may access a valid kernel object using legitimate system calls which it is not supposed to access.
You cannot directly call portSVC_RAISE_PRIVILEGE for raising privilege of an unprivileged task with mpu wrapper v2.

The process you are following correct, is making the application task a privileged task for it to be able to access Kernel objects.

You can read more about the access control of various tasks in the threat model here

3

You should ensure that the privileged task only does things that are needed to be done in privileged mode to minimize the threat surface. Refer to the threat model that @karahulx shared.

4

Thanks for you feedback. @karahulx @aggarg

By the way, with the existing system calls in mpu wrapper v2, is there any system calls that could help me read registers like Systick or NVIC ?

If it’s not possible, then seems the only thing I could do is to create a new privileged task to read register values for other application tasks. Am I correct ? feels a bit inefficient if other applications tasks need to wait for privileged task to read register for them…

Are mpu wrapper v1 and v2 meant to be co-exist in the future ? or eventually v1 would be deprecated and removed from the kernel release ?

5

No, there is no system call to read/write these registers directly.

Yes, that is correct.

We intend to keep both v1 and v2 as they serve different purpose:

  • V1 focuses on safety, enabling devices to recover in case of malfunctions.
  • V2 focuses on security, safeguarding devices against malicious threats.