Possibility of the zero-cost stack overflow protection

[bugadani]

Well, this is not necessarily an issue, but maybe some information that could be used as a starting point to bring back the stack overflow protection.

After reading the zero-cost stack overflow protection article and realizing that the cortex-m-rt-ld no longer works, I've found that the following statemenet is somewhat false:

We can’t specify the start address of .bss+.data to be 0x2000_4000 or some other fixed number because the correct number depends on the size of the .bss+.data section and linker scripts don’t provide support to get the size of an output section

At least on the current nightly, the following works:

  /* ## Sections in RAM */
  /* ### .data */
  .data ORIGIN(RAM) + LENGTH(RAM) - SIZEOF(.heap) - SIZEOF(.uninit) - SIZEOF(.bss) - SIZEOF(.data) - 4 : AT(__erodata) ALIGN(4)
  {
    . = ALIGN(4);
    __sdata = .;
    *(.data .data.*);
    . = ALIGN(4); /* 4-byte align the end (VMA) of this section */
    __edata = .;
  } > RAM

  /* LMA of .data */
  __sidata = LOADADDR(.data);

  /* ### .bss */
  .bss ORIGIN(RAM) + LENGTH(RAM) - SIZEOF(.heap) - SIZEOF(.uninit) - SIZEOF(.bss) - 4 (NOLOAD) : ALIGN(4)
  {
    . = ALIGN(4);
    __sbss = .;
    *(.bss .bss.*);
    . = ALIGN(4); /* 4-byte align the end (VMA) of this section */
    __ebss = .;
  } > RAM

  /* ### .uninit */
  .uninit ORIGIN(RAM) + LENGTH(RAM) - SIZEOF(.heap) - SIZEOF(.uninit) (NOLOAD) : ALIGN(4)
  {
    . = ALIGN(4);
    *(.uninit .uninit.*);
    . = ALIGN(4);
  } > RAM

  /* Heap */
  .heap ORIGIN(RAM) + LENGTH(RAM) - SIZEOF(.heap) (NOLOAD): ALIGN(4)
  {
    . = ALIGN(4);
    __sheap = .;
    *(.heap .heap.*);
    . = __sheap + __heap_size;
    __eheap = .;
  } > RAM

... and produces the following placement on an nRF52 with 64K RAM:

section               size         addr
.vector_table         0xdc          0x0
.text              0x14d6c         0xdc
.rodata             0x424c      0x14e50
.data                  0x0   0x2000cd58
.bss                 0xe5c   0x2000cd58
.uninit             0x1448   0x2000dbb8
.heap               0x1000   0x2000f000
[...]

I admit, it's not beautiful, but with PROVIDE(_stack_start = __sdata); (I think) I have the sections arranged in a way that implements the overflow protection, without double linking.

[jonas-schievink]

Does this still work with a non-empty .data section?

[bugadani]

It seems that way. Adding a static mut FOO: i32 = 5; and making sure it doesn't get optimized away, I get

section               size         addr
.vector_table         0xdc          0x0
.text              0x14d98         0xdc
.rodata             0x425c      0x14e80
.data                  0x4   0x2000cd54
.bss                 0xe5c   0x2000cd58
.uninit             0x1448   0x2000dbb8
.heap               0x1000   0x2000f000

[bugadani]

One thing I noticed is that cargo size adds the heap size to the value reported under data. I'm not sure how correct that is, but it's possible I just misrepresented the heap segment in some way. I'm not really fluent in linker speech. .heap just needed a (NOLOAD)

[hug-dev]

(also note that on Armv8-M, the MSPLIM and PSPLIM registers provide hardware checks of stack overflows, this PR added access)

[bugadani]

(also note that on Armv8-M, the MSPLIM and PSPLIM registers provide hardware checks of stack overflows, this PR added access)

That's neat, but I think it's a bit more device-specific than a memory segment reorder :) Unfortunately, a lot of devices out in the wild are v7-m, in my case a nRF52832.

I wonder whether this linker hackery could be implemented by default. Bypassing this is as simple as changing the .cargo/config file, so I think if someone needs custom memory segment placement, they are still able to do it.

[jonas-schievink]

I wonder whether this linker hackery could be implemented by default.

That would be great! The only thing that might be tricky is GNU LD support, have you checked if that also works? And from what I understand LLD aims to be compatible with GNU LD, so if it doesn't work in the latter, LLD might be "fixed" in the future and break this again.

(if it doesn't work in GNU LD then we could ship 2 different linker scripts, LLD is the default linker anyways, so users still get the stack overflow protection by default)

[bugadani]

It seems LD substitutes 0 in place of SIZEOF.

C:\gcc\bin\arm-none-eabi-ld.exe: address 0x20010fd4 of [...] section .bss' is not within region RAM'
C:\gcc\bin\arm-none-eabi-ld.exe: address 0x20011448 of [...] section .uninit' is not within region RAM'
C:\gcc\bin\arm-none-eabi-ld.exe: address 0x20011000 of [...] section .heap' is not within region RAM'

:(

[adamgreig]

That's a shame but not too surprising. I think these days LLD is generally usable so we could consider swapping to a linker script that only works with LD and provide the current script under a different name for use with gcc/ld. Stack overflow protection for free like this would be totally worth it IMO. I think it would have to be a breaking change for cortex-m-rt.

Of course, the ideal solution would be a linker script that does work the same with rustlld, arm-none-eabi-ld, and arm-none-eabi-gcc as linkers... even if it somehow only had stack protection for rustlld.

[bugadani]

This was fun while it lasted. Latest nightly rust-lld "broke" my hack. Oh well...

[jonas-schievink]

Such is life with linkers... Closing, but thanks for the investigation, @bugadani!