Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1305082

Re: sigaltstack breaks swapcontext()

From Andy Lutomirski <luto@amacapital.net>
Newsgroups linux.kernel
Subject Re: sigaltstack breaks swapcontext()
Date 2016-01-09 00:30 +0100
Message-ID <qOODM-5p4-17@gated-at.bofh.it> (permalink)
References <qNYvw-35F-21@gated-at.bofh.it> <qO0H1-4Es-17@gated-at.bofh.it> <qOFAw-7qR-33@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

sigaltstack breaks swapcontext() Stas Sergeev <stsp@list.ru> - 2016-01-06 16:50 +0100
  Re: sigaltstack breaks swapcontext() Andy Lutomirski <luto@amacapital.net> - 2016-01-06 19:10 +0100
    Re: sigaltstack breaks swapcontext() Stas Sergeev <stsp@list.ru> - 2016-01-06 19:50 +0100
      Re: sigaltstack breaks swapcontext() Andy Lutomirski <luto@amacapital.net> - 2016-01-06 20:20 +0100
        Re: sigaltstack breaks swapcontext() Stas Sergeev <stsp@list.ru> - 2016-01-06 20:40 +0100
          Re: sigaltstack breaks swapcontext() Andy Lutomirski <luto@amacapital.net> - 2016-01-06 21:00 +0100
            Re: sigaltstack breaks swapcontext() Stas Sergeev <stsp@list.ru> - 2016-01-07 16:40 +0100
              Re: sigaltstack breaks swapcontext() Andy Lutomirski <luto@amacapital.net> - 2016-01-07 18:30 +0100
                Re: sigaltstack breaks swapcontext() Stas Sergeev <stsp@list.ru> - 2016-01-07 20:20 +0100
    Re: sigaltstack breaks swapcontext() Stas Sergeev <stsp@list.ru> - 2016-01-08 14:50 +0100
      Re: sigaltstack breaks swapcontext() Andy Lutomirski <luto@amacapital.net> - 2016-01-09 00:30 +0100
        Re: sigaltstack breaks swapcontext() Stas Sergeev <stsp@list.ru> - 2016-01-09 00:50 +0100
        Re: sigaltstack breaks swapcontext() Andy Lutomirski <luto@amacapital.net> - 2016-01-09 02:50 +0100
        Re: sigaltstack breaks swapcontext() Stas Sergeev <stsp@list.ru> - 2016-01-09 02:50 +0100

csiph-web