FreeRTOS-MPU security (privileges)

scristalli wrote on Friday, August 16, 2013:

Hello, I am currently testing FreeRTOS-MPU on STM32F4, and it has occured to me that a restricted task could call library functions xTaskCreate or xTaskCreateRestricted in order to spawn other tasks, perhaps with malicious code inside them.
Is that a behavior that should be blocked? How would someone prevent such tasks from calling xTaskCreate?

Thanks in advance.

rtel wrote on Friday, August 16, 2013:

Currently there is no way of preventing a non-privileged task from creating a privileged task, but it could conceivable done relatively simply by updating the implementation of MPU_xTaskGenericCreate() in the MPU port layer’s port.c file.  The update would check to see if the scheduler was running, and if so, only allow a privileged task to be created if the MCU was already running in the privileged mode when MPU_xTaskGenericCreate() was called (that information is already known because it is stored in the xRunningPrivileged variable within the function).

However…in statically linked small systems there is an assumption that the system architecture is familiar with all the code s/he is building into the project.  It is therefore unlikely to include malicious code, so any additional safe guards would primarily safe guard against simple design mistakes.


supras wrote on Friday, July 19, 2019:

This thread is a little old, but I thouht I’ll mention the issue here as it’s related.

On freertos-mpu page ( there is stated that “A Privileged mode task can set itself into User mode, but once in User mode it cannot set itself back to Privileged mode.” which seems not true. User mode task switches itself to priviledged mode before every call to freertos api - on cortex-M4 it’s as simple as executing svc 2. I imagine that unintended execution of this instruction can happen as a result of memory corruption (if you are unlucky). Am I missing or misunderstaning something here?

Best regards, Jan Rydzewski

rtel wrote on Friday, July 19, 2019:

I think you have it right - note in the latest incarnation which is the
V8-M code (Cortex-M33) privileged escalation can only occur from within
the kernel’s executable code - otherwise an attempt to raise privilege
is just rejected.