On Tue, Oct 06, 2020 at 08:21:00PM +0200, Florian Weimer wrote:

* Dave Martin via Libc-alpha:

quoted

On Tue, Oct 06, 2020 at 08:33:47AM -0700, Dave Hansen wrote:

quoted

On 10/6/20 8:25 AM, Dave Martin wrote:

quoted

Or are people reporting real stack overruns on x86 today?

We have real overruns.  We have ~2800 bytes of XSAVE (regisiter) state
mostly from AVX-512, and a 2048 byte MINSIGSTKSZ.

Right.  Out of interest, do you believe that's a direct consequence of
the larger kernel-generated signal frame, or does the expansion of
userspace stack frames play a role too?

I must say that I do not quite understand this question.

32 64-*byte* registers simply need 2048 bytes of storage space worst
case, there is really no way around that.

If the architecture grows more or bigger registers, and if those
registers are used in general-purpose code, then all stack frames will
tend to grow, not just the signal frame.

So a stack overflow might be caused by the larger signal frame by
itself; or it might be caused by the growth of the stack of 20 function
frames created by someone's signal handler.

In the latter case, this is just a "normal" stack overflow, and nothing
really to do with signals or SIGSTKSZ.  Rebuilding with different
compiler flags could also grow the stack usage and cause just the same
problem.

I also strongly suspect that people often don't think about signal
nesting when allocating signal stacks.  So, there might be a pre-
existing potential overflow that just becomes more likely when the
signal frame grows.  That's not really SIGSTKSZ's fault.


Of course, AVX-512 might never be used in general-purpose code.  On
AArch64, SVE can be used in general-purpose code, but it's too early to
say what its prevalence will be in signal handlers.  Probably low.

quoted

In practice software just assumes SIGSTKSZ and then ignores the problem
until / unless an actual stack overflow is seen.

There's probably a lot of software out there whose stack is
theoretically too small even without AVX-512 etc. in the mix, especially
when considering the possibility of nested signals...

That is certainly true.  We have seen problems with ntpd, which
requested a 16 KiB stack, at a time when there were various deductions
from the stack size, and since the glibc dynamic loader also uses XSAVE,
ntpd exceeded the remaining stack space.  But in this case, we just
fudged the stack size computation in pthread_create and made it less
likely that the dynamic loader was activated, which largely worked
around this particular problem.  For MINSIGSTKSZ, we just don't have
this option because it's simply too small in the first place.

I don't immediately recall a bug due to SIGSTKSZ being too small.  The
test cases I wrote for this were all artificial, to raise awareness of
this issue (applications treating these as recommended values, rather
than minimum value to avoid immediately sigaltstack/phtread_create
failures, same issue with PTHREAD_STACK_MIN).

Ack, I think if SIGSTKSZ was too small significantly often, there would
be more awareness of the issue.

Cheers
---Dave