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

Groups > linux.kernel > #1302863 > unrolled thread

sigaltstack breaks swapcontext()

Back to article view | Back to linux.kernel

Contents

  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

#1302863 — sigaltstack breaks swapcontext()

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 work-around from this, is not even trivial: I have
to use the shm tricks to duplicate the sigaltstack in
the VA space, and move the stack pointer to another
mirror before calling sigaltstack. Then I use longjmp()
to restore the stack pointer. Then I can finally use
swapcontext(). This is an unpleasant work-around.

The fix on a kernel side looks simple: kernel should
just use ss_flags to determine whether the sigaltstack
is active. I can make a patch for that, but the problem
is that the arch-specific code is not using any helper
function to check for sigaltstack; instead it just uses
"if (ss_size)" checks. So the patch will need to update
all arches... I wonder if maybe someone can fix that
problem and update the arch-specific code. If not,
I'll probably need to update only the x86-specific code
and add an arch-specific define, which is a bit nasty.

Any suggestions?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1302943

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 see anything terribly wrong with allowing SS_DISABLE even if
you're on the alt stack.  You could also add a new flag SS_FORCE that
just overrides the check.

> The work-around from this, is not even trivial: I have
> to use the shm tricks to duplicate the sigaltstack in
> the VA space, and move the stack pointer to another
> mirror before calling sigaltstack. Then I use longjmp()
> to restore the stack pointer. Then I can finally use
> swapcontext(). This is an unpleasant work-around.
>
> The fix on a kernel side looks simple: kernel should
> just use ss_flags to determine whether the sigaltstack
> is active. I can make a patch for that, but the problem
> is that the arch-specific code is not using any helper
> function to check for sigaltstack; instead it just uses
> "if (ss_size)" checks.

Huh?  I'm not sure I understand what you're talking about.  It seems
reasonable to have the invariant that ss_size != 0 if and only if an
alt stack is enabled, and do_sigaltstack seems to enforce that
invariant.

> So the patch will need to update
> all arches... I wonder if maybe someone can fix that
> problem and update the arch-specific code. If not,
> I'll probably need to update only the x86-specific code
> and add an arch-specific define, which is a bit nasty.

Just change do_sigaltstack?

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1302976

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.
Could you please clarify?
If I set up another stack inside the sighandler, the
nested SA_ONSTACK signal can just use that new stack,
which seems safe and sane. So I don't think EPERM helps
the nested signals, or could you explain the possible breakage
scenario?

>> The work-around from this, is not even trivial: I have
>> to use the shm tricks to duplicate the sigaltstack in
>> the VA space, and move the stack pointer to another
>> mirror before calling sigaltstack. Then I use longjmp()
>> to restore the stack pointer. Then I can finally use
>> swapcontext(). This is an unpleasant work-around.
>>
>> The fix on a kernel side looks simple: kernel should
>> just use ss_flags to determine whether the sigaltstack
>> is active. I can make a patch for that, but the problem
>> is that the arch-specific code is not using any helper
>> function to check for sigaltstack; instead it just uses
>> "if (ss_size)" checks.
> Huh?  I'm not sure I understand what you're talking about.  It seems
> reasonable to have the invariant that ss_size != 0 if and only if an
> alt stack is enabled, and do_sigaltstack seems to enforce that
> invariant.
But we have that (IMO quite silly) requirement that the
returned oss->ss_flags is consistent.
So if inside the signal handler I use SS_DISABLE and
the kernel translates this into "ss_size = 0", the next
call to sigaltstack() will return 0 in oss->ss_flags.

>> So the patch will need to update
>> all arches... I wonder if maybe someone can fix that
>> problem and update the arch-specific code. If not,
>> I'll probably need to update only the x86-specific code
>> and add an arch-specific define, which is a bit nasty.
> Just change do_sigaltstack?
But if its that easy and we do not even need a consistent
oss->ss_flags - why not to remove the EPERM check entirely,
rather than only for SS_DISABLE? Note that if it is removed
only for SS_DISABLE and yet SS_DISABLE is translated to
"ss_size=0", then by the next sigaltstack() call you can do
whatever you want: the EPERM check will be entirely bypassed.
So if you are fine with even this, I can send the patch to
completely remove the check. Much easier for me. :)
I think the semantic of oss->ss_size is quite bad, but it is
already documented, so I am not sure.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1303014

On Wed, Jan 6, 2016 at 10:42 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.
>
> Could you please clarify?
> If I set up another stack inside the sighandler, the
> nested SA_ONSTACK signal can just use that new stack,
> which seems safe and sane. So I don't think EPERM helps
> the nested signals, or could you explain the possible breakage
> scenario?

It's probably safe in most cases, but the current behavior explicitly
checks whether you're on the alt stack during signal delivery, and
probably no one wanted to think about it too hard.

It might also avoid cases where you *free* the stack you're running
on.  Arguably that would be your fault.

>
>>> The work-around from this, is not even trivial: I have
>>> to use the shm tricks to duplicate the sigaltstack in
>>> the VA space, and move the stack pointer to another
>>> mirror before calling sigaltstack. Then I use longjmp()
>>> to restore the stack pointer. Then I can finally use
>>> swapcontext(). This is an unpleasant work-around.
>>>
>>> The fix on a kernel side looks simple: kernel should
>>> just use ss_flags to determine whether the sigaltstack
>>> is active. I can make a patch for that, but the problem
>>> is that the arch-specific code is not using any helper
>>> function to check for sigaltstack; instead it just uses
>>> "if (ss_size)" checks.
>>
>> Huh?  I'm not sure I understand what you're talking about.  It seems
>> reasonable to have the invariant that ss_size != 0 if and only if an
>> alt stack is enabled, and do_sigaltstack seems to enforce that
>> invariant.
>
> But we have that (IMO quite silly) requirement that the
> returned oss->ss_flags is consistent.
> So if inside the signal handler I use SS_DISABLE and
> the kernel translates this into "ss_size = 0", the next
> call to sigaltstack() will return 0 in oss->ss_flags.

It should returns SS_DISABLE, right?  And it won't set SS_ONSTACK
because you're not in the alt stack because there is no alt stack.

Of course, there *was* an alt stack when the signal was delivered, and
you're on that stack.

>
>>> So the patch will need to update
>>> all arches... I wonder if maybe someone can fix that
>>> problem and update the arch-specific code. If not,
>>> I'll probably need to update only the x86-specific code
>>> and add an arch-specific define, which is a bit nasty.
>>
>> Just change do_sigaltstack?
>
> But if its that easy and we do not even need a consistent
> oss->ss_flags - why not to remove the EPERM check entirely,
> rather than only for SS_DISABLE? Note that if it is removed
> only for SS_DISABLE and yet SS_DISABLE is translated to
> "ss_size=0", then by the next sigaltstack() call you can do
> whatever you want: the EPERM check will be entirely bypassed.
> So if you are fine with even this, I can send the patch to
> completely remove the check. Much easier for me. :)
> I think the semantic of oss->ss_size is quite bad, but it is
> already documented, so I am not sure.

I would send a patch to remove the check or a patch to add a new
SS_FORCE that disables the check.  It should be just a couple of lines
of code.  A selftests patch along with it would help.  Cc linux-abi on
all of it.

BTW, the sigcontext SS stuff is queued for -next.  I doubt it'll make
4.5 since I think that all the relevant maintainers are just
recovering from vacations, and I already have a decent backlog of
stuff that hasn't landed in -tip yet.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1303023

06.01.2016 22:14, Andy Lutomirski пишет:
> On Wed, Jan 6, 2016 at 10:42 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.
>> Could you please clarify?
>> If I set up another stack inside the sighandler, the
>> nested SA_ONSTACK signal can just use that new stack,
>> which seems safe and sane. So I don't think EPERM helps
>> the nested signals, or could you explain the possible breakage
>> scenario?
> It's probably safe in most cases, but the current behavior explicitly
> checks whether you're on the alt stack during signal delivery,
... to not re-use it occasionally.
But if you set up a new sigaltstack, then perhaps the
kernel can just check for overlaps with the current one to stay
safe (but I'd rather not check anything).

>>>> The work-around from this, is not even trivial: I have
>>>> to use the shm tricks to duplicate the sigaltstack in
>>>> the VA space, and move the stack pointer to another
>>>> mirror before calling sigaltstack. Then I use longjmp()
>>>> to restore the stack pointer. Then I can finally use
>>>> swapcontext(). This is an unpleasant work-around.
>>>>
>>>> The fix on a kernel side looks simple: kernel should
>>>> just use ss_flags to determine whether the sigaltstack
>>>> is active. I can make a patch for that, but the problem
>>>> is that the arch-specific code is not using any helper
>>>> function to check for sigaltstack; instead it just uses
>>>> "if (ss_size)" checks.
>>> Huh?  I'm not sure I understand what you're talking about.  It seems
>>> reasonable to have the invariant that ss_size != 0 if and only if an
>>> alt stack is enabled, and do_sigaltstack seems to enforce that
>>> invariant.
>> But we have that (IMO quite silly) requirement that the
>> returned oss->ss_flags is consistent.
>> So if inside the signal handler I use SS_DISABLE and
>> the kernel translates this into "ss_size = 0", the next
>> call to sigaltstack() will return 0 in oss->ss_flags.
> It should returns SS_DISABLE, right?
Who knows?
Man page says:
        SS_ONSTACK
               The process is  currently  executing  on  the alternate  
signal
               stack.   (Note  that  it is not possible to change the 
alternate
               signal stack if the process is currently executing on it.)

        SS_DISABLE
               The alternate signal stack is currently disabled.

Both applies, and, judging from the description of EPERM, I
can assume that SS_ONSTACK should be returned.
If we remove EPERM completely, then obviously SS_DISABLE
should be returned.

>    And it won't set SS_ONSTACK
> because you're not in the alt stack because there is no alt stack.
>
> Of course, there *was* an alt stack when the signal was delivered, and
> you're on that stack.
Exactly.
Do you think this can be ignored?
A man page should then be corrected with EPERM and the
above note removed, right?

>>>> So the patch will need to update
>>>> all arches... I wonder if maybe someone can fix that
>>>> problem and update the arch-specific code. If not,
>>>> I'll probably need to update only the x86-specific code
>>>> and add an arch-specific define, which is a bit nasty.
>>> Just change do_sigaltstack?
>> But if its that easy and we do not even need a consistent
>> oss->ss_flags - why not to remove the EPERM check entirely,
>> rather than only for SS_DISABLE? Note that if it is removed
>> only for SS_DISABLE and yet SS_DISABLE is translated to
>> "ss_size=0", then by the next sigaltstack() call you can do
>> whatever you want: the EPERM check will be entirely bypassed.
>> So if you are fine with even this, I can send the patch to
>> completely remove the check. Much easier for me. :)
>> I think the semantic of oss->ss_size is quite bad, but it is
>> already documented, so I am not sure.
> I would send a patch to remove the check or a patch to add a new
> SS_FORCE that disables the check.  It should be just a couple of lines
> of code.  A selftests patch along with it would help.  Cc linux-abi on
> all of it.
Hmm, OKey. But this can potentially contradict the man page,
and I fear it can be rejected.
So don't be surprised if I add your Acked-by, warning-warning. :)

> BTW, the sigcontext SS stuff is queued for -next.  I doubt it'll make
> 4.5 since I think that all the relevant maintainers are just
> recovering from vacations, and I already have a decent backlog of
> stuff that hasn't landed in -tip yet.
Thanks for taking care of that!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1303030

On Wed, Jan 6, 2016 at 11:31 AM, Stas Sergeev <stsp@list.ru> wrote:
> 06.01.2016 22:14, Andy Lutomirski пишет:
>
>> On Wed, Jan 6, 2016 at 10:42 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.
>>>
>>> Could you please clarify?
>>> If I set up another stack inside the sighandler, the
>>> nested SA_ONSTACK signal can just use that new stack,
>>> which seems safe and sane. So I don't think EPERM helps
>>> the nested signals, or could you explain the possible breakage
>>> scenario?
>>
>> It's probably safe in most cases, but the current behavior explicitly
>> checks whether you're on the alt stack during signal delivery,
>
> ... to not re-use it occasionally.
> But if you set up a new sigaltstack, then perhaps the
> kernel can just check for overlaps with the current one to stay
> safe (but I'd rather not check anything).
>
>>>>> The work-around from this, is not even trivial: I have
>>>>> to use the shm tricks to duplicate the sigaltstack in
>>>>> the VA space, and move the stack pointer to another
>>>>> mirror before calling sigaltstack. Then I use longjmp()
>>>>> to restore the stack pointer. Then I can finally use
>>>>> swapcontext(). This is an unpleasant work-around.
>>>>>
>>>>> The fix on a kernel side looks simple: kernel should
>>>>> just use ss_flags to determine whether the sigaltstack
>>>>> is active. I can make a patch for that, but the problem
>>>>> is that the arch-specific code is not using any helper
>>>>> function to check for sigaltstack; instead it just uses
>>>>> "if (ss_size)" checks.
>>>>
>>>> Huh?  I'm not sure I understand what you're talking about.  It seems
>>>> reasonable to have the invariant that ss_size != 0 if and only if an
>>>> alt stack is enabled, and do_sigaltstack seems to enforce that
>>>> invariant.
>>>
>>> But we have that (IMO quite silly) requirement that the
>>> returned oss->ss_flags is consistent.
>>> So if inside the signal handler I use SS_DISABLE and
>>> the kernel translates this into "ss_size = 0", the next
>>> call to sigaltstack() will return 0 in oss->ss_flags.
>>
>> It should returns SS_DISABLE, right?
>
> Who knows?
> Man page says:
>        SS_ONSTACK
>               The process is  currently  executing  on  the alternate
> signal
>               stack.   (Note  that  it is not possible to change the
> alternate
>               signal stack if the process is currently executing on it.)
>
>        SS_DISABLE
>               The alternate signal stack is currently disabled.
>
> Both applies, and, judging from the description of EPERM, I
> can assume that SS_ONSTACK should be returned.
> If we remove EPERM completely, then obviously SS_DISABLE
> should be returned.
>
>>    And it won't set SS_ONSTACK
>> because you're not in the alt stack because there is no alt stack.
>>
>> Of course, there *was* an alt stack when the signal was delivered, and
>> you're on that stack.
>
> Exactly.
> Do you think this can be ignored?
> A man page should then be corrected with EPERM and the
> above note removed, right?
>

I think it can be ignored.  I'd go the SS_FORCE route, though, to
maintain POSIX compliance.

>>>>> So the patch will need to update
>>>>> all arches... I wonder if maybe someone can fix that
>>>>> problem and update the arch-specific code. If not,
>>>>> I'll probably need to update only the x86-specific code
>>>>> and add an arch-specific define, which is a bit nasty.
>>>>
>>>> Just change do_sigaltstack?
>>>
>>> But if its that easy and we do not even need a consistent
>>> oss->ss_flags - why not to remove the EPERM check entirely,
>>> rather than only for SS_DISABLE? Note that if it is removed
>>> only for SS_DISABLE and yet SS_DISABLE is translated to
>>> "ss_size=0", then by the next sigaltstack() call you can do
>>> whatever you want: the EPERM check will be entirely bypassed.
>>> So if you are fine with even this, I can send the patch to
>>> completely remove the check. Much easier for me. :)
>>> I think the semantic of oss->ss_size is quite bad, but it is
>>> already documented, so I am not sure.
>>
>> I would send a patch to remove the check or a patch to add a new
>> SS_FORCE that disables the check.  It should be just a couple of lines
>> of code.  A selftests patch along with it would help.  Cc linux-abi on
>> all of it.
>
> Hmm, OKey. But this can potentially contradict the man page,
> and I fear it can be rejected.
> So don't be surprised if I add your Acked-by, warning-warning. :)
>

You can add my Suggested-by.  No Acked-by until I actually ack it,
which involves seeing the code :)

>> BTW, the sigcontext SS stuff is queued for -next.  I doubt it'll make
>> 4.5 since I think that all the relevant maintainers are just
>> recovering from vacations, and I already have a decent backlog of
>> stuff that hasn't landed in -tip yet.
>
> Thanks for taking care of that!



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1303668

06.01.2016 22:53, Andy Lutomirski пишет:
> On Wed, Jan 6, 2016 at 11:31 AM, Stas Sergeev <stsp@list.ru> wrote:
>> Exactly.
>> Do you think this can be ignored?
>> A man page should then be corrected with EPERM and the
>> above note removed, right?
>>
> I think it can be ignored.  I'd go the SS_FORCE route, though, to
> maintain POSIX compliance.
I think such a flag would be a wrong thing to do.
Allowing only SS_DISABLE (without any new flags) keeps
you still "compatible with posix", and anything beyond
SS_DISABLE in a sighandler is not needed.

So I think we only have the following options:
1. Remove the check and forget (if anything, glibc can
add the EPERM check to stay compatible with crap).
2. Allow only SS_DISABLE. This will mean a large patch,
touching all arches, but the bonus is the compatibility
with posix, that no one needs in this particular case.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1303752

On Thu, Jan 7, 2016 at 7:33 AM, Stas Sergeev <stsp@list.ru> wrote:
> 06.01.2016 22:53, Andy Lutomirski пишет:
>>
>> On Wed, Jan 6, 2016 at 11:31 AM, Stas Sergeev <stsp@list.ru> wrote:
>>>
>>> Exactly.
>>> Do you think this can be ignored?
>>> A man page should then be corrected with EPERM and the
>>> above note removed, right?
>>>
>> I think it can be ignored.  I'd go the SS_FORCE route, though, to
>> maintain POSIX compliance.
>
> I think such a flag would be a wrong thing to do.
> Allowing only SS_DISABLE (without any new flags) keeps
> you still "compatible with posix", and anything beyond
> SS_DISABLE in a sighandler is not needed.
>
> So I think we only have the following options:
> 1. Remove the check and forget (if anything, glibc can
> add the EPERM check to stay compatible with crap).
> 2. Allow only SS_DISABLE. This will mean a large patch,
> touching all arches, but the bonus is the compatibility
> with posix, that no one needs in this particular case.

Why does allowing SS_DISABLE require touching all arches?

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1303831

07.01.2016 20:23, Andy Lutomirski пишет:
> On Thu, Jan 7, 2016 at 7:33 AM, Stas Sergeev <stsp@list.ru> wrote:
>> 06.01.2016 22:53, Andy Lutomirski пишет:
>>> On Wed, Jan 6, 2016 at 11:31 AM, Stas Sergeev <stsp@list.ru> wrote:
>>>> Exactly.
>>>> Do you think this can be ignored?
>>>> A man page should then be corrected with EPERM and the
>>>> above note removed, right?
>>>>
>>> I think it can be ignored.  I'd go the SS_FORCE route, though, to
>>> maintain POSIX compliance.
>> I think such a flag would be a wrong thing to do.
>> Allowing only SS_DISABLE (without any new flags) keeps
>> you still "compatible with posix", and anything beyond
>> SS_DISABLE in a sighandler is not needed.
>>
>> So I think we only have the following options:
>> 1. Remove the check and forget (if anything, glibc can
>> add the EPERM check to stay compatible with crap).
>> 2. Allow only SS_DISABLE. This will mean a large patch,
>> touching all arches, but the bonus is the compatibility
>> with posix, that no one needs in this particular case.
> Why does allowing SS_DISABLE require touching all arches?
I mean, if we also consistently return SA_ONSTACK even
after SS_DISABLE. This will require kernel to save the
ss_flags separately, and not to use "if (ss_size)" checks.
Of course if we don't want to return SA_ONSTACK, we
should just remove EPERM as I don't think it serves any
other purpose than that.

[toc] | [prev] | [next] | [standalone]

#1304557

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).

[toc] | [prev] | [next] | [standalone]

#1305082

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

[toc] | [prev] | [next] | [standalone]

#1305088

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.

[toc] | [prev] | [next] | [standalone]

#1305131

On Fri, Jan 8, 2016 at 5:43 PM, Stas Sergeev <stsp@list.ru> wrote:
> 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.
>
> 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

[toc] | [prev] | [next] | [standalone]

#1305132

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.
Will you take care of this one?
Looks quite dangerous for dosemu! And absolutely
undebuggable: you never know when you hit it.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web