Hardening FreeRTOS Applications
FreeRTOS runs on a huge share of 32-bit embedded products, and by default every task shares one flat address space with no isolation. A bug in the least important task can corrupt the most important one. A few configuration choices change that. Here is how to harden a FreeRTOS application.
Why Default FreeRTOS Is Soft
FreeRTOS optimizes for footprint and flexibility, not isolation. Out of the box, tasks share memory, run privileged, and a stack overflow corrupts whatever is adjacent rather than being caught. That is fine for a prototype and dangerous for a shipped product with any attack surface.
Turning On Protection
The key switches live in FreeRTOSConfig. Enabling the MPU port and the stack-overflow hook is the biggest single improvement:
#define configENABLE_MPU 1 #define configCHECK_FOR_STACK_OVERFLOW 2 #define configUSE_MPU_WRAPPERS_V1 0
Catching the Overflow
With the hook enabled, a task that overruns its stack lands in your handler instead of silently corrupting memory:
void vApplicationStackOverflowHook(TaskHandle_t t, char *name) {
log_fault(name);
NVIC_SystemReset();
}
[FAULT] stack overflow in task: 'net_rx' System reset
The overflow is caught and named, the system resets to a known state, and one task’s bug does not become a whole-device compromise.
Three FreeRTOS Hardening Wins
If you change three things, change these:
Going Further
Run application tasks unprivileged so a compromised one cannot touch peripherals it should not, choose a heap scheme that suits your allocation pattern, and back the whole system with a watchdog that resets on a hang. Isolation plus fail-safe reset is the RTOS equivalent of defense in depth.
Where This Fits
Reviewing RTOS configuration and task isolation on a shipping product is part of a product security assessment. That review is the kind of work we do at Berkner Tech.