Support stack canaries in LLVM Libc

[mxms0]

LLVM Libc today doesn't support stack canaries (aka stack protectors, stack cookies, -fstack-protector).

I'm not sure of the full implementation details required, but the tl;dr is:

• On thread creation, fs:0x28 (TLS base + 0x28) should be set to a mostly randomized value.
• Generally this value has the least-significant byte set to 0, so that linear string functions like strlen stop before reading it (in the case where a string is missing a null terminator). This helps preventing leaking the cookie in some cases.
• Implement __stack_chk_fail to handle aborting when the stack cookie is corrupted. The compiler expects this to be there iiuc.
• Maybe provide a relocatable symbol to tell the linker/loader that nothing else should go at that offset, even though it's been somewhat fixed for ~10 years now.

In addition, to improve where others are lacking, we should try and put guard pages around TLS, to prevent other regions from being mapped contiguously with TLS. This may be expensive for some consumers that create a lot of threads, so we may need an opt-out. But we can judge the performance characteristics once we get there. TLS should be randomized as well, but I think this is already the case.

[llvmbot]

@llvm/issue-subscribers-libc

[sivachandra]

@Maximus- In your report, you mentioned the current mechanism employed by the libc and the compilers on x86. For non-x86, it seems like compilers lookup a global symbol by name __stack_chk_guard. I think it is worth making compilers and the libc use a uniform pattern on all architectures. Say, the libc will store the stack cookie in a thread local variable named __stack_chk_guard on thread creation and then compilers will read that thread local variable on function entry and exit. Does it sound reasonable? If yes, would you be willing to take this up in LLVM? I am assigning this issue to you but feel free to assign it back to me.

[matheusmoreira]

@sivachandra

I think it is worth making compilers and the libc use a uniform pattern on all architectures.

This sounds perfectly reasonable to me.

Say, the libc will store the stack cookie in a thread local variable named __stack_chk_guard on thread creation and then compilers will read that thread local variable on function entry and exit.

This is probably a fine implementation for the standard library but could make things very complicated for -ffreestanding -nostdlib programs. The stack smashing protector is also used in freestanding environments without standard library support. For example, there's a detailed article on the OSDev Wiki explaining how to implement a custom handler that integrates with the compiler's machinery. So I think it's worth it to keep such machinery as simple as possible.

[MolassesLover]

Any updates on this?

[michaelrj-google]

It got implemented a while back. Here's where it lives in the source: https://github.com/llvm/llvm-project/blob/main/libc/src/compiler/generic/__stack_chk_fail.cpp https://github.com/llvm/llvm-project/blob/main/libc/startup/linux/x86_64/tls.cpp#L67

I'm going to close this issue since it's complete.