Filing this to loop Gentoo into a bug I hit that involves all of golang, the kernel, and the Gentoo Hardened toolchain.
* sys-devel/gcc-6.4.0 (Gentoo Hardened 6.4.0 p1.0)
This combination causes GCC to compile the time-related kernel vDSO code (arch/x86/entry/vdso/vclock_gettime.o) without inlining `vread_tsc` (which is not marked inline, so that's OK). That turns those vDSO functions into non-leaf functions since they make a call. -fstack-check then inserts a stack probe into them.
Unfortunately Go assumes that the vDSO functions won't use more than 104 bytes of stack space, while the probe is at a 4K offset. This causes hard to debug random crashes when the non-atomic stack probe races another thread that actually owns that memory, causing corruption.
Go bug: https://github.com/golang/go/issues/20427#issuecomment-343255844
Kernel discussion: https://lkml.org/lkml/2017/11/10/188
Andy (kernel vDSO maintainer) says Gentoo should turn -fstack-check off, which I disagree with. I think this is a Go bug (assuming vDSO stack usage with no documented guarantee).
Thanks for your blog post
I presume now it's ok to close this since Go fixed the issue?
Sure, I just wanted to file this to make sure the Gentoo team was aware of the issue too. Looking forward to GCC 8 which should have saner Stack Clash protection.
Let's close, this is long fixed (and I think these days the kernel filters out -fstack-check anyway).