Re: [PATCH v7 5/6] x86/signal: Detect and prevent an alternate signal stack overflow

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.

quoted

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@intel.com

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