Unprivileged tasks are not permitted to enter critical sections because, if allowed, a misbehaving unprivileged task could enter a critical section and deliberately not exit, bringing the system to a halt. The configALLOW_UNPRIVILEGED_CRITICAL_SECTIONS configuration option in ARM-v7M ports exists solely for backward compatibility and its use is discouraged.
For more details on the security considerations, please refer to the FreeRTOS Kernel Threat Model: Kernel threat model - FreeRTOS™.
Once done, please upstream your port as it could benefit the broader FreeRTOS community.
Thanks for confirming—absolutely want to contribute if possible.
But there seems to be significant uncertainty here, because RISC-V’s PMP (Physical Memory Protection) does not govern memory access permissions in M-mode—unless the lock bit is set. This stands in sharp contrast to Cortex-M’s MPU (Memory Protection Unit), which cancontrol access for privileged modes.
Additionally, pvPortMalloc()does not support specifying alignment granularity. If configSUPPORT_DYNAMIC_ALLOCATIONis enabled, on platforms with a large PMP granularity (e.g., 256 Byte), RTOS objects allocated from the FreeRTOS heap fail to meet the required alignment.
I am not very familiar with PMP but does it mean that we need to run tasks in U-mode and only kernel runs in M-mode?
For this one, you can enforce that all the tasks must be created using xTaskCreateRestricted APIs and the application writer must supply the correctly aligned stack.