Messages in this thread | | | Date | Wed, 17 Mar 2021 11:44:15 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH v7 0/6] x86: Improve Minimum Alternate Stack Size |
| |
* Ingo Molnar <mingo@kernel.org> wrote:
> > * Chang S. Bae <chang.seok.bae@intel.com> wrote: > > > During signal entry, the kernel pushes data onto the normal userspace > > stack. On x86, the data pushed onto the user stack includes XSAVE state, > > which has grown over time as new features and larger registers have been > > added to the architecture. > > > > MINSIGSTKSZ is a constant provided in the kernel signal.h headers and > > typically distributed in lib-dev(el) packages, e.g. [1]. Its value is > > compiled into programs and is part of the user/kernel ABI. The MINSIGSTKSZ > > constant indicates to userspace how much data the kernel expects to push on > > the user stack, [2][3]. > > > > However, this constant is much too small and does not reflect recent > > additions to the architecture. For instance, when AVX-512 states are in > > use, the signal frame size can be 3.5KB while MINSIGSTKSZ remains 2KB. > > > > The bug report [4] explains this as an ABI issue. The small MINSIGSTKSZ can > > cause user stack overflow when delivering a signal. > > > uapi: Define the aux vector AT_MINSIGSTKSZ > > x86/signal: Introduce helpers to get the maximum signal frame size > > x86/elf: Support a new ELF aux vector AT_MINSIGSTKSZ > > selftest/sigaltstack: Use the AT_MINSIGSTKSZ aux vector if available > > x86/signal: Detect and prevent an alternate signal stack overflow > > selftest/x86/signal: Include test cases for validating sigaltstack > > So this looks really complicated, is this justified? > > Why not just internally round up sigaltstack size if it's too small? > This would be more robust, as it would fix applications that use > MINSIGSTKSZ but don't use the new AT_MINSIGSTKSZ facility. > > I.e. does AT_MINSIGSTKSZ have any other uses than avoiding the > segfault if MINSIGSTKSZ is used to create a small signal stack?
I.e. if the kernel sees a too small ->ss_size in sigaltstack() it would ignore ->ss_sp and mmap() a new sigaltstack instead and use that for the signal handler stack.
This would automatically make MINSIGSTKSZ - and other too small sizes work today, and in the future.
But the question is, is there user-space usage of sigaltstacks that relies on controlling or reading the contents of the stack?
longjmp using programs perhaps?
Thanks,
Ingo
| |