On Tue, Oct 06, 2020 at 08:21:00PM +0200, Florian Weimer wrote: > * Dave Martin via Libc-alpha: > > > On Tue, Oct 06, 2020 at 08:33:47AM -0700, Dave Hansen wrote: > >> On 10/6/20 8:25 AM, Dave Martin wrote: > >> > 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. > > 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
