Approximated stack overflow detection via stack canaries

[jonas-schievink]

While it is possible to link an embedded app in a way that will detect stack overflows immediately and (mostly) reliably, few people actually do this as it requires using a linker wrapper to link the app twice. cortex-m-rt also doesn't do it by default at the moment.

However, we can still do our best to help out when no built-in stack overflow protection is used: After uploading the program, but before starting it, we can fill the space in RAM right after the data used by ELF sections with a unique pattern. Then, after the program exits (or even while it still runs), we scan the filled area and look for bytes that were changed from our pattern. If we find any changed bytes, there is a high probability that the program has used too much stack and overwrote its own data sections.

There are a few things to keep in mind here:

• When "real" stack overflow protection is used, the ELF sections will be at the end of RAM, and our canary won't fit anywhere (but is also unnecessary).
• This is all relying on luck and is a post-mortem technique: The program state is already undefined when we detect the stack overflow.
• We need to fill "enough" RAM with the canary to get a high chance of detecting the overflow, but only as much RAM as is needed (otherwise, even regular stack usage will trip the canary).
• It is currently unclear how this interacts with program that use the heap. It probably has to be disabled then, as the heap usually starts right after the fixed ELF sections.
• While this feature has both false positives and negatives, I believe it can be enabled by default if the message is worded right. Something like "program has used at least N bytes of stack space, collision with data segments is likely". This can be worded differently based on where in the canary the modification was detected.

[japaric]

even while it still runs

I would be against this particular variant. Polling a second memory block can easily halve the throughput of the log stream data and probe-rs's RTT implementation is already rather slow.

It is currently unclear how this interacts with program that use the heap.

I don't think there are strong guidelines but either a chunk of .bss memory will be used as the heap or the .heap section defined in cortex-m-rt will be sized accordingly and the whole section will be passed to the memory allocator.

---

Related feature: optionally we can "paint" all the potential stack memory with a known pattern and once the program has finished we look for the "watermark" level and report the max stack usage for this particular program run.

[jonas-schievink]

It seems that c-m-rt places the heap start symbol __sheap right after .uninit in RAM, but not inside any section:

https://github.com/rust-embedded/cortex-m-rt/blob/3ce46b3c19158cb9be4f9d2a3c00d5723e62ded5/link.x.in#L139-L141

That means there's no section we can use to detect presence of a heap. Can we detect whether the symbol was referenced by looking for it in the ELF file or will it always be there?

[jonas-schievink]

I guess for compatibility with other runtimes we could look for any symbol that points to the first address after .uninit. There shouldn't be any reason to refer to that address unless you use a heap.

[jonas-schievink]

Looks like __sheap is always present even when it's not used by anything :/