linux-kernel - Re: sigaltstack breaks swapcontext()

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 8 Jan 2016 17:48:13 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Stas Sergeev <stsp@...t.ru>
Cc:	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: sigaltstack breaks swapcontext()

On Fri, Jan 8, 2016 at 5:43 PM, Stas Sergeev <stsp@...t.ru> wrote:
> 09.01.2016 02:24, Andy Lutomirski пишет:
>>
>> On Fri, Jan 8, 2016 at 5:49 AM, Stas Sergeev <stsp@...t.ru> wrote:
>>
>>> 06.01.2016 21:05, Andy Lutomirski пишет:
>>>>
>>>> On Wed, Jan 6, 2016 at 7:45 AM, Stas Sergeev <stsp@...t.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.
>
> 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