On Mon, May 03, 2021 at 07:30:21AM +0200, Florian Weimer wrote: > Just to be clear, I'm worried about the case where an application > installs a stack overflow handler, but stack overflow does not regularly > happen at run time. GNU m4 is an example. Today, for most m4 scripts, > it's totally fine to have an alternative signal stack which is too > small. If the kernel returned an error for the sigaltstack call, m4 > wouldn't start anymore, independently of the script. Which is worse > than memory corruption with some scripts, I think. Oh lovely. > > > Or is this use case obsolete and this is not what people do at all? > > It's widely used in currently-maintained software. It's the only way to > recover from stack overflows without boundary checks on every function > call. > > Does the alternative signal stack actually have to contain the siginfo_t > data? I don't think it has to be contiguous. Maybe the kernel could > allocate and map something behind the processes back if the sigaltstack > region is too small? So there's an attempt floating around to address this: https://lkml.kernel.org/r/20210422044856.27250-1-chang.seok.bae@xxxxxxxxx esp patch 3. I'd appreciate having a look and sanity-checking this whether it makes sense and could be useful this way... > And for the stack overflow handler, the kernel could treat SIGSEGV with > a sigaltstack region that is too small like the SIG_DFL handler. This > would make m4 work again. /me searches a bit about SIG_DFL... Do you mean that the default action in this case should be what SIGSEGV does by default - to dump core? Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
