Cortex-M hardware stack overflow detection

[brucehoult]

Wasting in what sense?

[ataradov]

You need to setup the protected region that would trigger a fault when a write happens. In general in MCUs all SRAM is technically "used" and there is no way to tell what is stack and what is not. With MMU you could map those regions far apart in the address space and have a way easier time detecting issues.

And I think the smallest MPU region size is 256 bytes, so you will be wasting even more.

[brucehoult]

Ahhh .. in RISC-V "no access" is the default, and you'd just enable R/W access to the stack and data/bss/heap region(s) and R/X access to the code.

[ataradov]

But there are no regions generally. There is no way any system can know if a write at some address is a legitimate write to the variable at that address or a stack overflow into that address.

Obviously if you are not using all the SRAM, you can define the middle section as unused in a platform specific way. But the question is why? If you have some memory left after the variables are allocated, you might as well allocate it for the heap/stack.

And this is where you need to decide how much of that memory in the middle you are willing to waste. Obviously if you don't have a lot of data and you can limit your stack to a very small size, you can declare most of the SRAM as RO, but this is not a typical scenario.

[ejeffrey]

If you use your compilers call graph analysis tool and find the largest stack frame of any single function and you can afford to waste that much memory, then you should be able to mostly protect against stack / heap collisions by marking that much space read only.  If on activation of a function the storing the return address doesn't fault, then the local variables of that function should not be able to touch the heap.  You have to add a check to alloca and avoid or check variable size arrays and the like if you use them.

This will only keep the stack allocated space from colliding with the heap.  It won't stop out of bounds indexing of automatic arrays from doing pretty much anything.  However I still think it's a win.  Bounds checking is a local problem and amenable to local solutions.  Stack overflow is a global problem, so a series of individually correct functions can have incorrect behavior.  Also, more often buffer overflows are positive overflow which won't impact the heap in a conventional layout but will be just as damaging by overwriting the rest of the stack.

[westfw]

in RISC-V "no access" is the default, and you'd just enable R/W access to the stack and data/bss/heap region(s) and R/X access to the code.

I don't see how that's different.  You're "wasting" any RAM set for "no access."
(now we can argue about whether it makes any sense to call "not used RAM" "wasted."  These days it is relatively easy to just pick a chip with more ram than you need.)

[brucehoult]

in RISC-V "no access" is the default, and you'd just enable R/W access to the stack and data/bss/heap region(s) and R/X access to the code.

I don't see how that's different.  You're "wasting" any RAM set for "no access."
(now we can argue about whether it makes any sense to call "not used RAM" "wasted."  These days it is relatively easy to just pick a chip with more ram than you need.)

It's not unused, it's used by other threads.

If you're allocating all of RAM for your [ stack : data : bss : heap ] then you just let it trap with "unmapped address" (or whatever it's called) if the stack overflows the RAM area downwards or the brk upwards and don't need to bother with the protection mechanism.