(Zero cost) stack overflow protection

[japaric]

Today, the layout of RAM looks like this (assuming no heap and a single RAM region):

With this layout when a stack overflow occurs static variables end up being overwritten /
corrupted silently.

This scenario can be avoided by simply changing the memory layout to look like this:

In this new scenario a stack overflow will hit the lower RAM boundary. Trying to write beyond the
RAM boundaries raises a HardFault exception. Thus, in theory, the HardFault exception handler
could be used as a stack overflow handler.

In systems where heap memory, which by default starts where the static region ends and grows
upwards, exists a similar reordering of the regions can be applied.

Implementation

To my knowledge this can't be implement using only linker scripts. With a linker script you can
instruct the linker where to start a memory region but you can't specify the end address of the
region.

The related bits of the linker script we use are shown below:

PROVIDE(_stack_start = ORIGIN(RAM) + LENGTH(RAM));

SECTIONS
{
  /* .. */
  .bss : ALIGN(4)
  {
    _sbss = .;
    *(.bss .bss.*);
    . = ALIGN(4);
    _ebss = .;
  } > RAM

  .data : ALIGN(4)
  {
    _sidata = LOADADDR(.data);
    _sdata = .;
    *(.data .data.*);
    . = ALIGN(4);
    _edata = .;
  } > RAM AT > FLASH

  /* The heap starts right after the .bss + .data section ends */
  _sheap = _edata;

  /* .. */
}

A C implementation of this region reordering uses a two step linking process. See
this StackOverflow answer for details.

Other options for stack overflow protection

Assuming that we can't change the memory layout. We could:

• Use the MPU (Memory Protection Unit) to mark the upper boundary of the static region as
  read-only. In this scenario when a stack overflow occurs a MemManage exception is raised. This has
  an initialization cost but no runtime cost. The downside is that not all microcontrollers have a
  MPU.

• Implement stack probes for the Cortex-M targets. I believe enabling stack probes carries a runtime
  cost (per function call?) but I'm not sure.

[pftbest]

You can achieve a similar result if you set a fixed size for a stack. You just create a section with that size at the beginning of RAM, and set the stack pointer to the end of a section.

Downside is that you waste some memory at the end.

[japaric]

@pftbest Yeah, I thought about that option but decided not to include it here because it seems to be very fram far from ideal. Reasons: (a) it requires user input (there's no sensible default, I think), (b) it's error-prone (e.g. if the selected stack space is too large you'll get an error about not being enough space to fit the static variables) and (c) it's not efficient (if you pick a stack size that's too small then you leave space unused, what you mentioned).

[whitequark]

Implement stack probes for the Cortex-M targets. I believe enabling stack probes carries a runtime
cost (per function call?) but I'm not sure.

Stack probes only (currently) exist in Rust to avoid "jumping over" the guard page of the thread stack and into the heap. The old mechanism, which relied on segmented stacks and TLS slots, is dead and it would be really annoying to resurrect for this issue.

[whitequark]

@japaric Anyway, I know how to do this. Place the static sections twice. The first time you place them, they go into /dev/null (via /DISCARD/ or something) but you can get the size with the SIZEOF operator. The second time, you use that result. So it's two-pass linking in one ld invocation.

[ia0]

Hi,

It looks like the fix in #43 was reverted as a side-effect of #64 as far as I understand. It looks like no support from cortex-m-rt is actually need to get stack overflow protection as well as maximum heap usage (related to #5) by using a memory.x like the following:

__stack_size = 0x10000;

MEMORY
{
  FLASH : ORIGIN = 0x00000000, LENGTH = 0x00100000
  RAM   : ORIGIN = 0x20000000 + __stack_size, LENGTH = 0x00040000 - __stack_size
}

_stack_start = ORIGIN(RAM);
__eheap = ORIGIN(RAM) + LENGTH(RAM);

Then initializing the heap with:

extern "C" {
    static mut __sheap: u32;
    static mut __eheap: u32;
}
let sheap = unsafe { &mut __sheap } as *mut u32 as usize;
let eheap = unsafe { &mut __eheap } as *mut u32 as usize;
assert!(sheap < eheap);
// Unsafe: Called only once before any allocation.
unsafe { ALLOCATOR.init(sheap, eheap - sheap) }

However, I wonder if cortex-m-rt should help the user to achieve this. I'm not sure how, so I'm asking in this issue. I can open a new issue if needed.

Thanks!