# portSVC\_RAISE\_PRIVILEGE behaves differently in mpu wrapper v1 and v2

**URL:** <https://forums.freertos.org/t/portsvc-raise-privilege-behaves-differently-in-mpu-wrapper-v1-and-v2/22285>\
**Category:** Kernel\
**Created:** [January 20, 2025, 2:44am UTC](https://forums.freertos.org/t/portsvc-raise-privilege-behaves-differently-in-mpu-wrapper-v1-and-v2/22285 "2025-01-20T02:44:35Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![pasu](https://avatars.discourse-cdn.com/v4/letter/p/46a35a/32.png) [@pasu](https://forums.freertos.org/u/pasu)\
**Post date:** [January 20, 2025, 2:44am UTC](https://forums.freertos.org/t/portsvc-raise-privilege-behaves-differently-in-mpu-wrapper-v1-and-v2/22285/1 "2025-01-20T02:44:35Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![karahulx](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/karahulx/32/4893_2.png) [@karahulx](https://forums.freertos.org/u/karahulx)\
**Post date:** [January 20, 2025, 7:29am UTC](https://forums.freertos.org/t/portsvc-raise-privilege-behaves-differently-in-mpu-wrapper-v1-and-v2/22285/2 "2025-01-20T07:29:00Z")

</div>

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](https://www.freertos.org/Security/02-Kernel-threat-model)

---

<div class="post-metadata">

**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\
**Post date:** [January 20, 2025, 7:44am UTC](https://forums.freertos.org/t/portsvc-raise-privilege-behaves-differently-in-mpu-wrapper-v1-and-v2/22285/3 "2025-01-20T07:44:25Z")

</div>

> [@pasu](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![pasu](https://avatars.discourse-cdn.com/v4/letter/p/46a35a/32.png) [@pasu](https://forums.freertos.org/u/pasu)\
**Post date:** [January 20, 2025, 10:20pm UTC](https://forums.freertos.org/t/portsvc-raise-privilege-behaves-differently-in-mpu-wrapper-v1-and-v2/22285/4 "2025-01-20T22:20:39Z")

</div>

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 ?

---

<div class="post-metadata">

**Author:** ![aggarg](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/aggarg/32/4245_2.png) [@aggarg](https://forums.freertos.org/u/aggarg)\
**Post date:** [January 21, 2025, 4:40am UTC](https://forums.freertos.org/t/portsvc-raise-privilege-behaves-differently-in-mpu-wrapper-v1-and-v2/22285/5 "2025-01-21T04:40:46Z")

</div>

> [@pasu](#):
>
> is there any system calls that could help me read registers like Systick or NVIC ?

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

> [@pasu](#):
>
> the only thing I could do is to create a new privileged task to read register values for other application tasks. Am I correct ?

Yes, that is correct.

> [@pasu](#):
>
> Are mpu wrapper v1 and v2 meant to be co-exist in the future ?

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.