(Blocks 637152) Filing this to loop Gentoo into a bug I hit that involves all of golang, the kernel, and the Gentoo Hardened toolchain. * sys-kernel/gentoo-sources-4.13.9 * sys-devel/gcc-6.4.0 (Gentoo Hardened 6.4.0 p1.0) * CONFIG_OPTIMIZE_INLINING=n 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). Thoughts?
marcan: Thanks for your blog post https://marcan.st/2017/12/debugging-an-evil-go-runtime-bug/ 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).
