[Feature Request] When using MPU_WRAPPERS v2, prevent critical sections in unprivileged tasks

[wbemont]

Is your feature request related to a problem? Please describe.
We are using FreeRTOS v11.2 with the ARM_CM4_MPU port. This configuration allows critical sections to be created in unprivileged tasks. This situation is problematic because it can result in very difficult-to-debug latent faults that may occur after many hours of normal operation. We lost many days of development time due to having to debug this issue. A quick summary from @aggarg (with whom we were consulting):

We cannot support critical sections in unprivileged tasks. It is implemented as follows:

1. configALLOW_UNPRIVILEGED_CRITICAL_SECTIONS uses portRAISE_PRIVILEGE: https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/portable/GCC/ARM_CM4_MPU/port.c#L1024
2. portRAISE_PRIVILEGE raises SVC portSVC_RAISE_PRIVILEGE: https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/portable/GCC/ARM_CM4_MPU/portmacro.h#L382
3. portSVC_RAISE_PRIVILEGEis a no-op for MPU wrapper v2: https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/portable/GCC/ARM_CM4_MPU/port.c#L475-L505. As a result, privilege is not raised and BASEPRI programming is no-op.

Describe the solution you'd like
One way to address this would be to disallow configurations where configALLOW_UNPRIVILEGED_CRITICAL_SECTIONS is set to 1 while configUSE_MPU_WRAPPERS_V1 is set to 0. This could be accomplished with an assertion that will fail if these conditions are true simultaneously.

Describe alternatives you've considered
Another way this could be addressed might be to add an assertion to catch portSVC_RAISE_PRIVILEGEin MPU wrapper V2, possibly by adding an assertion that will fail on this line. However, this may be too general and would likely require extensive testing.

How many devices will this feature impact?
Thousands of high-value devices

What are your project timelines?
We have worked around the issue for now by no longer using critical sections in unprivileged tasks. We would like this enhancement to be made as soon as reasonably possible, though, to give us (and others) protection against this situation in the future.

Additional context
Add any other context or screenshots about the feature request here.

If you have the same (or similar) feature request, please upvote this issue with thumbs up 👍
and use the comments section to provide answers to the questions above.