Stack canaries

[mchack-work]

Implement stack canaries to help against buffer overflows. lld gives:

ld.lld: error: undefined symbol: __stack_chk_guard

ld.lld: error: undefined symbol: __stack_chk_fail

which hints at what we need to implement.

[cobratbq]

I was looking into the same functionality recently. embeddedartistry.com provides a comprehensive post on this topic. (Other than this post, I found mostly snippets of information.)
Given the lack of much runtime support, it seems that one must call function that performs the init manually, or include it right before call main in libcrt0/crt0.S.

Note that there is one minor consideration: if one includes the init-call in crt0.S, then main is no longer called with unmodified program memory.

[cobratbq]

A quick summary of where I'm at. In case this is something you want to tackle soon.

Makefile:

• add -fstack-protector-all or -fstack-protector-strong to build-options.

some-tkey-lib.c:

// `__stack_chk_guard_init_tkey` returns a value from TRNG.
// ref: <https://embeddedartistry.com/blog/2020/05/18/implementing-stack-smashing-protection-for-microcontrollers-and-embedded-artistrys-libc/>
// Note: `__attribute__((no_stack_protector))` is needed to exempt `__stack_chk_guard_init_tkey`
// from `-fstack-protector-all` such that it is allowed to initialize `_stack_chk_guard`.
uintptr_t __attribute__((no_stack_protector)) __stack_chk_guard_init_tkey(void) {
	return *tk1_trng_source;
}

// default implementation for __stack_chk_fail that enters an abort-loop. (stack-protector)
// Note: function is marked "weak", so it may be overridden in user applications.
__attribute__((weak,noreturn))
void __stack_chk_fail(void) {
	abort();
}

main.c:

uintptr_t __stack_chk_guard = 0xdeadb007;

__attribute__((noreturn,no_stack_protector)) int main(void) {
  __stack_chk_guard = __stack_chk_guard_init_tkey();
  [...]
}

shell:

llvm-objdump --disassemble-symbols=__stack_chk_fail,main,reply_encrypted program.out

I haven't recently triggered stack-protection manually. The compiler is annoyingly competent in cleaning out violations. Object-dumping aptly demonstrates its presence. Hope this gives you some indication. These snippets are enough to make LLVM think that all base components are present for stack-protection, and on an older version of Clang, I triggered it when originally setting it up.

update, for completeness: I haven't yet inspected whether proper value is taken from TRNG as run-time stack-guard value. It seems like little can go wrong on this part.