Re: libsigsegv on LinuxFromScratch

[Paul Eggert]

On 9/19/20 4:47 PM, Bruno Haible wrote:

>         havelib: Avoid linking with libc.a on GNU systems.

Thanks for fixing the bug. This caused me to look at the c-stack module for the 
first time in a while, and I found some old-fashioned code and some unlikely 
bugs and fixed one misfeature when libsigsegv is not in use. I installed the 
attached patches to the c-stack module in Gnulib to try to fix it. These changes 
shouldn't affect how c-stack behaves when libsigsegv is in use.

While looking into this I discovered pthread_getattr_np + pthread_attr_getstack 
which might have been nice for the GNU/Linux part of c-stack.c, except they're 
not async-signal-safe. As I understand it, libsigsegv works around the 
async-signal-safe problem by parsing /proc/self/maps with async-signal-safe 
functions, which is quite a feat and is probably beyond what c-stack should do.

PS. I also found this circa-2015 Linux kernel bug related to PIE that looks like 
it might be of interest to the libsigsegv developers

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000253

This bug causes /proc/self/maps to report the wrong VMA (actually, overlapping 
VMAs) for the stack. This could be worth a comment in the libsigsegv sources. 
For more commentary in this area please see:

https://stackoverflow.com/questions/56893353/analyzing-memory-mapping-of-a-process-with-pmap-stack/56920770

PPS. Given the longstanding security problems with stack overflow (as witness 
the name stackoverflow.com!) it is somewhat disturbing that there is still no 
reliable way in GNU/Linux to answer the simple question "Where's my stack?" or 
to detect and recover from stack overflow reliably. What's up with that?

0001-c-stack-improve-checking-if-libsigsegv.patch
Description: Text Data

0002-c-stack-output-diagnostic-in-single-write.patch
Description: Text Data