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

Groups > linux.kernel > #1413649 > unrolled thread

SIGSYS annoyance

Back to article view | Back to linux.kernel

Contents

  SIGSYS annoyance Andy Lutomirski <luto@amacapital.net> - 2016-06-04 07:20 +0200
    Re: SIGSYS annoyance Kees Cook <keescook@chromium.org> - 2016-06-06 18:10 +0200
      Re: SIGSYS annoyance Andy Lutomirski <luto@amacapital.net> - 2016-06-09 19:30 +0200
        Re: SIGSYS annoyance Mikael Pettersson <mikpelinux@gmail.com> - 2016-06-10 11:10 +0200

#1413649 — SIGSYS annoyance

https://bugzilla.mozilla.org/show_bug.cgi?id=1176099

Should SIGSYS be delivered to the handler even if blocked?  What, if
anything, does POSIX say?  All I can find is in pthread_sigmask(3p):

If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS signals are generated
while they are blocked, the result is undefined, unless the signal was
generated by the action of another process, or by one of the functions
kill(), pthread_kill(), raise(), or sigqueue().

It would be easy enough to change our behavior so that we deliver the
signal even if it's blocked or to at least add a flag so that users
can request that behavior.

[toc] | [next] | [standalone]

#1415247

On Fri, Jun 3, 2016 at 10:16 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1176099
>
> Should SIGSYS be delivered to the handler even if blocked?  What, if
> anything, does POSIX say?  All I can find is in pthread_sigmask(3p):
>
> If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS signals are generated
> while they are blocked, the result is undefined, unless the signal was
> generated by the action of another process, or by one of the functions
> kill(), pthread_kill(), raise(), or sigqueue().
>
> It would be easy enough to change our behavior so that we deliver the
> signal even if it's blocked or to at least add a flag so that users
> can request that behavior.

I had trouble following that bug. It sounded like glib just needed a
way to define its signal mask, and that's what they ended up
implementing?

I think the current behavior is correct. SIGSYS is being generated by
the running process (i.e. the seccomp filter) and if it has a handler
but the signal is blocked, we should treat it as uncaught and kill. On
the other hand, it could be seen like "raise", in which case the
blocking should be ignored? Is there an active problem somewhere here?
It seems like the referenced bug has been fixed already.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

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

#1418518

On Mon, Jun 6, 2016 at 9:03 AM, Kees Cook <keescook@chromium.org> wrote:
> On Fri, Jun 3, 2016 at 10:16 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1176099
>>
>> Should SIGSYS be delivered to the handler even if blocked?  What, if
>> anything, does POSIX say?  All I can find is in pthread_sigmask(3p):
>>
>> If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS signals are generated
>> while they are blocked, the result is undefined, unless the signal was
>> generated by the action of another process, or by one of the functions
>> kill(), pthread_kill(), raise(), or sigqueue().
>>
>> It would be easy enough to change our behavior so that we deliver the
>> signal even if it's blocked or to at least add a flag so that users
>> can request that behavior.
>
> I had trouble following that bug. It sounded like glib just needed a
> way to define its signal mask, and that's what they ended up
> implementing?
>
> I think the current behavior is correct. SIGSYS is being generated by
> the running process (i.e. the seccomp filter) and if it has a handler
> but the signal is blocked, we should treat it as uncaught and kill. On
> the other hand, it could be seen like "raise", in which case the
> blocking should be ignored? Is there an active problem somewhere here?
> It seems like the referenced bug has been fixed already.

Agreed.

It could make sense to have a new sigaction flag SA_FORCE: when set,
if a non-default handler is installed, the signal is blocked, and the
signal is triggered synchronously (forced), then the handler will be
called.  But that isn't specific to seccomp.

--Andy

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

#1419137

Andy Lutomirski writes:
 > On Mon, Jun 6, 2016 at 9:03 AM, Kees Cook <keescook@chromium.org> wrote:
 > > On Fri, Jun 3, 2016 at 10:16 PM, Andy Lutomirski <luto@amacapital.net> wrote:
 > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1176099
 > >>
 > >> Should SIGSYS be delivered to the handler even if blocked?  What, if
 > >> anything, does POSIX say?  All I can find is in pthread_sigmask(3p):
 > >>
 > >> If any of the SIGFPE, SIGILL, SIGSEGV, or SIGBUS signals are generated
 > >> while they are blocked, the result is undefined, unless the signal was
 > >> generated by the action of another process, or by one of the functions
 > >> kill(), pthread_kill(), raise(), or sigqueue().
 > >>
 > >> It would be easy enough to change our behavior so that we deliver the
 > >> signal even if it's blocked or to at least add a flag so that users
 > >> can request that behavior.
 > >
 > > I had trouble following that bug. It sounded like glib just needed a
 > > way to define its signal mask, and that's what they ended up
 > > implementing?
 > >
 > > I think the current behavior is correct. SIGSYS is being generated by
 > > the running process (i.e. the seccomp filter) and if it has a handler
 > > but the signal is blocked, we should treat it as uncaught and kill. On
 > > the other hand, it could be seen like "raise", in which case the
 > > blocking should be ignored? Is there an active problem somewhere here?
 > > It seems like the referenced bug has been fixed already.
 > 
 > Agreed.
 > 
 > It could make sense to have a new sigaction flag SA_FORCE: when set,
 > if a non-default handler is installed, the signal is blocked, and the
 > signal is triggered synchronously (forced), then the handler will be
 > called.  But that isn't specific to seccomp.

Blocking a signal is a very deliberate act.  If some piece of code wants
to force-deliver it, it can unblock it first.  IOW, I don't see the need
for this SA_FORCE thing.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web