sigaltstack breaks swapcontext()

DISCUSSION Stas Sergeev 3 participants 20 messages Jan 6, 2016 – Mar 7, 2016

Share & tools

Stas Sergeev

author

2016-01-06 15:45 UTC #0 lore raw

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?

Andy Lutomirski

2016-01-06 18:05 UTC #1 lore raw

Quoted 13 lines · Stas Sergeev

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.

Quoted 9 lines

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.

Quoted 7 lines

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.

Quoted 6 lines

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.

Quoted 5 lines

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

Stas Sergeev

author

2016-01-06 18:42 UTC #2 lore raw

06.01.2016 21:05, Andy Lutomirski пишет:

Quoted 23 lines · Stas Sergeev

Quoted 13 lines
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.
Quoted 9 lines
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.

Quoted 2 lines

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?

Quoted 13 lines

Quoted 7 lines
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.
Quoted 6 lines
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.

Quoted 4 lines

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.

Quoted 6 lines

Quoted 5 lines
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.

Andy Lutomirski

2016-01-06 19:14 UTC #3 lore raw

Quoted 29 lines · Stas Sergeev

06.01.2016 21:05, Andy Lutomirski пишет:
Quoted 25 lines · Stas Sergeev
Quoted 14 lines
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.
Quoted 9 lines
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.
Quoted 2 lines
The EPERM thing is probably also to preserve the behavior that nested SA_ONSTACK signals are supposed to work.

Quoted 6 lines

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.

Quoted 20 lines

Quoted 15 lines
Quoted 8 lines
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.
Quoted 6 lines
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.
Quoted 4 lines
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.

Quoted 5 lines

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.

Quoted 9 lines

Quoted 8 lines
Quoted 6 lines
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?

Quoted 10 lines

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

Stas Sergeev

author

2016-01-06 19:31 UTC #4 lore raw

06.01.2016 22:14, Andy Lutomirski пишет:

Quoted 27 lines · Stas Sergeev

Quoted 26 lines
06.01.2016 21:05, Andy Lutomirski пишет:
Quoted 25 lines · Stas Sergeev
Quoted 13 lines
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.
Quoted 9 lines
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.

Quoted 8 lines

Quoted 6 lines
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).

Quoted 17 lines

Quoted 17 lines
Quoted 17 lines
Quoted 7 lines
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.
Quoted 6 lines
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.

Quoted 6 lines

Quoted 5 lines
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.

Quoted 5 lines

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?

Quoted 16 lines

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
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?
Quoted 10 lines
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.

Quoted 4 lines

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

Quoted 4 lines

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

2016-01-06 19:53 UTC #5 lore raw

Quoted 95 lines · Stas Sergeev

06.01.2016 22:14, Andy Lutomirski пишет:
Quoted 38 lines · Stas Sergeev
Quoted 30 lines
06.01.2016 21:05, Andy Lutomirski пишет:
Quoted 25 lines · Stas Sergeev
Quoted 14 lines
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.
Quoted 9 lines
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.
Quoted 2 lines
The EPERM thing is probably also to preserve the behavior that nested SA_ONSTACK signals are supposed to work.
Quoted 6 lines
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?
Quoted 2 lines
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).
Quoted 19 lines
Quoted 19 lines
Quoted 18 lines
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 7 lines
Quoted 5 lines
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.
Quoted 3 lines
And it won't set SS_ONSTACK
because you're not in the alt stack because there is no alt stack.

Quoted 8 lines

Quoted 2 lines
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.

Quoted 19 lines

Quoted 19 lines
Quoted 18 lines
Quoted 7 lines
Quoted 5 lines
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.

Quoted 9 lines

Quoted 4 lines
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 :)

Quoted 6 lines

Quoted 4 lines
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!

Signature · 2 lines

Andy Lutomirski
AMA Capital Management, LLC

Stas Sergeev

author

2016-01-07 15:35 UTC #6 lore raw

06.01.2016 22:53, Andy Lutomirski пишет:

Quoted 8 lines · Stas Sergeev

Quoted 5 lines
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.

Andy Lutomirski

2016-01-07 17:23 UTC #7 lore raw

Quoted 17 lines · Stas Sergeev

06.01.2016 22:53, Andy Lutomirski пишет:
Quoted 10 lines · Stas Sergeev
Quoted 6 lines
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.

Quoted 6 lines

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

Signature · 2 lines

Andy Lutomirski
AMA Capital Management, LLC

Stas Sergeev

author

2016-01-07 19:10 UTC #8 lore raw

07.01.2016 20:23, Andy Lutomirski пишет:

Quoted 15 lines · Stas Sergeev

Quoted 14 lines
06.01.2016 22:53, Andy Lutomirski пишет:
Quoted 8 lines · Stas Sergeev
Quoted 5 lines
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.

Quoted 7 lines

Quoted 6 lines
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.

Stas Sergeev

author

2016-01-08 13:49 UTC #9 lore raw

In reply to Andy Lutomirski

06.01.2016 21:05, Andy Lutomirski пишет:

Quoted 23 lines · Stas Sergeev

Quoted 13 lines
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.
Quoted 9 lines
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.

Quoted 4 lines

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

Andy Lutomirski

2016-01-08 23:24 UTC #10 lore raw

Quoted 31 lines · Stas Sergeev

06.01.2016 21:05, Andy Lutomirski пишет:
Quoted 25 lines · Stas Sergeev
Quoted 14 lines
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.
Quoted 9 lines
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.
Quoted 4 lines
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.)

Quoted 4 lines

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

Signature · 2 lines

Andy Lutomirski
AMA Capital Management, LLC

Stas Sergeev

author

2016-01-08 23:40 UTC #11 lore raw

09.01.2016 02:24, Andy Lutomirski пишет:

Quoted 30 lines · Stas Sergeev

Quoted 29 lines
06.01.2016 21:05, Andy Lutomirski пишет:
Quoted 28 lines · Stas Sergeev
Quoted 14 lines
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.
Quoted 9 lines
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.)

Quoted 8 lines

Quoted 4 lines
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.

Stas Sergeev

author

2016-01-09 01:43 UTC #12 lore raw

In reply to Andy Lutomirski

09.01.2016 02:24, Andy Lutomirski пишет:

Quoted 30 lines · Stas Sergeev

Quoted 29 lines
06.01.2016 21:05, Andy Lutomirski пишет:
Quoted 28 lines · Stas Sergeev
Quoted 14 lines
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.
Quoted 9 lines
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.)

Quoted 8 lines

Quoted 4 lines
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.

Andy Lutomirski

2016-01-09 01:48 UTC #13 lore raw

Quoted 40 lines · Stas Sergeev

09.01.2016 02:24, Andy Lutomirski пишет:
Quoted 39 lines · Stas Sergeev
Quoted 36 lines
06.01.2016 21:05, Andy Lutomirski пишет:
Quoted 25 lines · Stas Sergeev
Quoted 14 lines
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.
Quoted 9 lines
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.
Quoted 4 lines
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).

Quoted 8 lines

Quoted 4 lines
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

Stas Sergeev

author

2016-03-07 20:02 UTC #14 lore raw

09.01.2016 04:48, Andy Lutomirski пишет:

Quoted 10 lines · Stas Sergeev

Quoted 8 lines
09.01.2016 02:24, Andy Lutomirski пишет:
Quoted 4 lines
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.

How is this one going?
There seem to be one more bug in sigcontext handling.
dosemu have this code:
---
/*
* FIRST thing to do in signal handlers - to avoid being trapped into
int0x11
* forever, we must restore the eflags.
*/
loadflags(eflags_fs_gs.eflags);
---

I quickly checked the kernel code, and it seems the flags are indeed forgotten, even on ia32! I think the most dangerous flags are AC and NT. But most of others are important too. IMHO the safe defaults should be forced when entering the sighandler. Would you mind taking a look at this problem too?

Andy Lutomirski

2016-03-07 21:10 UTC #15 lore raw

Quoted 29 lines · Stas Sergeev

09.01.2016 04:48, Andy Lutomirski пишет:
Quoted 10 lines · Stas Sergeev
Quoted 8 lines
09.01.2016 02:24, Andy Lutomirski пишет:
Quoted 5 lines
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.
Quoted 5 lines
Quoted 3 lines
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.
How is this one going?
There seem to be one more bug in sigcontext handling.
dosemu have this code:
---
/*
* FIRST thing to do in signal handlers - to avoid being trapped into
int0x11
* forever, we must restore the eflags.
*/
loadflags(eflags_fs_gs.eflags);
---

Quoted 6 lines

I quickly checked the kernel code, and it seems the flags are indeed forgotten, even on ia32! I think the most dangerous flags are AC and NT. But most of others are important too. IMHO the safe defaults should be forced when entering the sighandler. Would you mind taking a look at this problem too?

Clearing NT seems sane.

Clearing AC seems like an ABI break, so I'd be a bit nervous about clearing AC unconditionally. We could add yet another SS flag (sigh), or we could make the change. As a more conservative option, we could make it so that AC is cleared on entry to an alignment check signal.

--Andy

Signature · 2 lines

Andy Lutomirski
AMA Capital Management, LLC

Stas Sergeev

author

2016-03-07 21:21 UTC #16 lore raw

08.03.2016 00:10, Andy Lutomirski пишет:

Quoted 8 lines · Stas Sergeev

Quoted 7 lines
09.01.2016 04:48, Andy Lutomirski пишет:
Quoted 6 lines · Stas Sergeev
Quoted 5 lines
09.01.2016 02:24, Andy Lutomirski пишет:
Quoted 4 lines
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.

Quoted 5 lines

Quoted 5 lines
Quoted 4 lines
Quoted 3 lines
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.
How is this one going?

So what do you think about checking SS when
evaluating the on_sig_stack condition? Will you
fix this, or should I try?

Quoted 17 lines

Quoted 11 lines
There seem to be one more bug in sigcontext handling.
dosemu have this code:
---
/*
* FIRST thing to do in signal handlers - to avoid being trapped into
int0x11
* forever, we must restore the eflags.
*/
loadflags(eflags_fs_gs.eflags);
---
Quoted 6 lines
I quickly checked the kernel code, and it seems the flags are indeed forgotten, even on ia32! I think the most dangerous flags are AC and NT. But most of others are important too. IMHO the safe defaults should be forced when entering the sighandler. Would you mind taking a look at this problem too?

Quoted 4 lines

Clearing NT seems sane.
Clearing AC seems like an ABI break, so I'd be a bit nervous about clearing AC unconditionally.

What exactly do you mean? Is this a documented part of ABI? Where can I find out how the flags are supposed to be set on entering a sighandler, any docs on that?
I thought they should just be forced to some default value, the same as the segregs are handled.

Quoted 1 line

We could add yet another SS flag (sigh),

But this is not a sigreturn() problem and not sigaltstack() problem, so what exactly flag do you mean?

Quoted 2 lines

or we could make the change. As a more conservative option, we could make it so that AC is cleared on entry to an alignment check signal.

Hmm. But if we deliver such signal, the userspace will still crash, so what's the use?

Andy Lutomirski

2016-03-07 21:32 UTC #17 lore raw

Quoted 19 lines · Stas Sergeev

08.03.2016 00:10, Andy Lutomirski пишет:
Quoted 18 lines · Stas Sergeev
Quoted 16 lines
09.01.2016 04:48, Andy Lutomirski пишет:
Quoted 14 lines · Stas Sergeev
Quoted 11 lines
09.01.2016 02:24, Andy Lutomirski пишет:
Quoted 5 lines
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.

Quoted 7 lines

Quoted 3 lines
Quoted 3 lines
Quoted 1 line
I'll try to remember to tack it on to the sigcontext series.
How is this one going?
So what do you think about checking SS when
evaluating the on_sig_stack condition? Will you
fix this, or should I try?

It fits in with your series, and you're welcome to do it. You can also poke me and get me to do it.

Quoted 21 lines

Quoted 21 lines
Quoted 12 lines
There seem to be one more bug in sigcontext handling.
dosemu have this code:
---
/*
* FIRST thing to do in signal handlers - to avoid being trapped into
int0x11
* forever, we must restore the eflags.
*/
loadflags(eflags_fs_gs.eflags);
---
Quoted 6 lines
I quickly checked the kernel code, and it seems the flags are indeed forgotten, even on ia32! I think the most dangerous flags are AC and NT. But most of others are important too. IMHO the safe defaults should be forced when entering the sighandler. Would you mind taking a look at this problem too?
Clearing NT seems sane.

Quoted 8 lines

Quoted 2 lines
Clearing AC seems like an ABI break, so I'd be a bit nervous about clearing AC unconditionally.
What exactly do you mean? Is this a documented part of ABI? Where can I find out how the flags are supposed to be set on entering a sighandler, any docs on that?
I thought they should just be forced to some default value, the same as the segregs are handled.

ABI is that which existing programs rely on, which may or may not be related to any docs. If there are AC users and they want their signal handlers to be protected by AC, then this change would break them.

Quoted 5 lines

Quoted 2 lines
We could add yet another SS flag (sigh),
But this is not a sigreturn() problem and not sigaltstack() problem, so what exactly flag do you mean?

I meant SA_ flag, not SS_. Whoops.

Quoted 6 lines

Quoted 3 lines
or we could make the change. As a more conservative option, we could make it so that AC is cleared on entry to an alignment check signal.
Hmm. But if we deliver such signal, the userspace will still crash, so what's the use?

Userspace could handle the SIGBUS and clear AC from regs->flags if they were so inclined.

Anyway, maybe Linus or the x86 maintainers have some idea of how AC is used. If there are people who use it for a whole program and if libc can survive the experience, then they might expect even signal handlers to run with AC set. But if they're sane and protect just critical pieces of code being tested with AC, we could be polite and clear AC on signal handler entry.

--Andy

Signature · 2 lines

Andy Lutomirski
AMA Capital Management, LLC

One Thousand Gnomes

2016-03-07 21:38 UTC #18 lore raw

Quoted 6 lines

Anyway, maybe Linus or the x86 maintainers have some idea of how AC is used. If there are people who use it for a whole program and if libc can survive the experience, then they might expect even signal handlers to run with AC set. But if they're sane and protect just critical pieces of code being tested with AC, we could be polite and clear AC on signal handler entry.

No idea about AC and signals but the main use I have seen is type checking, particularly in old 16bit code.

Basically code does add type to address, deference. If the type is wrong for the address you get an alignment trap.

Alan

Stas Sergeev

author

2016-03-07 21:45 UTC #19 lore raw

In reply to Andy Lutomirski

08.03.2016 00:32, Andy Lutomirski пишет:

Quoted 42 lines · Stas Sergeev

Quoted 9 lines
08.03.2016 00:10, Andy Lutomirski пишет:
Quoted 8 lines · Stas Sergeev
Quoted 7 lines
09.01.2016 04:48, Andy Lutomirski пишет:
Quoted 6 lines · Stas Sergeev
Quoted 5 lines
09.01.2016 02:24, Andy Lutomirski пишет:
Quoted 4 lines
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.
Quoted 8 lines
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
Quoted 3 lines
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.
How is this one going?
So what do you think about checking SS when
evaluating the on_sig_stack condition? Will you
fix this, or should I try?
It fits in with your series, and you're welcome to do it. You can also poke me and get me to do it.
Quoted 21 lines
Quoted 21 lines
Quoted 9 lines
There seem to be one more bug in sigcontext handling.
dosemu have this code:
---
/*
* FIRST thing to do in signal handlers - to avoid being trapped into
int0x11
     * forever, we must restore the eflags.
     */
    loadflags(eflags_fs_gs.eflags);
Quoted 8 lines
---
I quickly checked the kernel code, and it seems the flags are indeed forgotten, even on ia32! I think the most dangerous flags are AC and NT. But most of others are important too. IMHO the safe defaults should be forced when entering the sighandler. Would you mind taking a look at this problem too?
Clearing NT seems sane.
Clearing AC seems like an ABI break, so I'd be a bit nervous about clearing AC unconditionally.

Quoted 8 lines

Quoted 5 lines
What exactly do you mean? Is this a documented part of ABI? Where can I find out how the flags are supposed to be set on entering a sighandler, any docs on that?
I thought they should just be forced to some default value, the same as the segregs are handled.
ABI is that which existing programs rely on, which may or may not be related to any docs. If there are AC users and they want their signal handlers to be protected by AC, then this change would break them.

But aren't such users (I am sure there are none who use AC in a sighandler) supposed to set the AC flag explicitly in a sighandler? I just thought this is a bug, not an ABI feature at all. So no one should rely on that IMHO.

Quoted 4 lines

Quoted 3 lines
Quoted 1 line
We could add yet another SS flag (sigh),
But this is not a sigreturn() problem and not sigaltstack() problem, so what exactly flag do you mean?
I meant SA_ flag, not SS_. Whoops.

But you said "yet another", and we haven't yet added any SA_ flag here. :)

Quoted 6 lines

Quoted 4 lines
Quoted 2 lines
or we could make the change. As a more conservative option, we could make it so that AC is cleared on entry to an alignment check signal.
Hmm. But if we deliver such signal, the userspace will still crash, so what's the use?
Userspace could handle the SIGBUS and clear AC from regs->flags if they were so inclined.

Oh, no, I'd better leave popf in the beginning of a sighandler, as it is now done in dosemu. :)

Quoted 4 lines

Anyway, maybe Linus or the x86 maintainers have some idea of how AC is used. If there are people who use it for a whole program and if libc can survive the experience, then they might expect even signal handlers to run with AC set.

I wonder how do they get such an expectation.
It is likely a bug, unexpected behaviour. I wonder if someone could expect this, and I really doubt someone needs AC in a sighandler.
So I agree, lets see what other people think, and if there are no couter arguments, lets just force eflags to the default.