Re: sigaltstack breaks swapcontext()

[Stas Sergeev <stsp@list.ru>]

09.01.2016 02:24, Andy Lutomirski пишет:
> On Fri, Jan 8, 2016 at 5:49 AM, Stas Sergeev <stsp@list.ru> wrote:
>> 06.01.2016 21:05, Andy Lutomirski пишет:
>>> On Wed, Jan 6, 2016 at 7:45 AM, Stas Sergeev <stsp@list.ru> wrote:
>>>
>>>> Hello.
>>>>
>>>> swapcontext() can be used with signal handlers,
>>>> it swaps the signal masks together with the other
>>>> parts of the context.
>>>> Unfortunately, linux implements the sigaltstack()
>>>> in a way that makes it impossible to use with
>>>> swapcontext().
>>>> Per the man page, sigaltstack is allowed to return
>>>> EPERM if the process is altering its sigaltstack while
>>>> running on sigaltstack. This is likely needed to
>>>> consistently return oss->ss_flags, that indicates
>>>> whether the process is being on sigaltstack or not.
>>>> Unfortunately, linux takes that permission to return
>>>> EPERM too literally: it returns EPERM even if you
>>>> don't want to change to another sigaltstack, but
>>>> only want to disable sigaltstack with SS_DISABLE.
>>>> To my reading of a man page, this is not a desired
>>>> behaviour. Moreover, you can't use swapcontext()
>>>> without disabling sigaltstack first, or the stack will
>>>> be re-used and overwritten by a subsequent signal.
>>>>
>>> The EPERM thing is probably also to preserve the behavior that nested
>>> SA_ONSTACK signals are supposed to work.  (Of course, the kernel gets
>>> this a bit wrong because it forgets to check ss in addition to sp.
>>> That would be relatively straightforward to fix.)
>> I don't think it needs a fix: in 64bit mode SS doesn't matter, and
>> in 32bit mode the SS is properly restored in a sighandler, so no
>> one can run sigaltstack() with non-flat SS (unless the DOS code
>> itself does this, which it does not).
> It's not sigaltstack that I'm thinking about.  It's signal delivery.
> If you end up in DOS mode with SP coincidentally pointing to the
> sigaltstack (but with different SS so it's not really the
> sigaltstack), then the signal delivery will malfunction.
Ah, sounds like a real bug then!
Though if bitness differ (64bit mode and signal comes from
32bit code), there is probably no need to check anything and
just switch the stack.