Re: sigaltstack breaks swapcontext()

[Andy Lutomirski]

On Fri, Jan 8, 2016 at 5:43 PM, Stas Sergeev <stsp@xxxxxxx> wrote:
> 09.01.2016 02:24, Andy Lutomirski ÐÐÑÐÑ:
>>
>> On Fri, Jan 8, 2016 at 5:49 AM, Stas Sergeev <stsp@xxxxxxx> wrote:
>>
>>> 06.01.2016 21:05, Andy Lutomirski ÐÐÑÐÑ:
>>>>
>>>> On Wed, Jan 6, 2016 at 7:45 AM, Stas Sergeev <stsp@xxxxxxx> 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.
>
> Will you take care of this one?
> Looks quite dangerous for dosemu! And absolutely
> undebuggable: you never know when you hit it.

I'll try to remember to tack it on to the sigcontext series.

--Andy