* SIGSYS annoyance @ 2016-06-04 5:16 Andy Lutomirski 2016-06-06 16:03 ` Kees Cook 0 siblings, 1 reply; 4+ messages in thread From: Andy Lutomirski @ 2016-06-04 5:16 UTC (permalink / raw) To: Kees Cook, linux-kernel 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: SIGSYS annoyance 2016-06-04 5:16 SIGSYS annoyance Andy Lutomirski @ 2016-06-06 16:03 ` Kees Cook 2016-06-09 17:21 ` Andy Lutomirski 0 siblings, 1 reply; 4+ messages in thread From: Kees Cook @ 2016-06-06 16:03 UTC (permalink / raw) To: Andy Lutomirski; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: SIGSYS annoyance 2016-06-06 16:03 ` Kees Cook @ 2016-06-09 17:21 ` Andy Lutomirski 2016-06-10 9:08 ` Mikael Pettersson 0 siblings, 1 reply; 4+ messages in thread From: Andy Lutomirski @ 2016-06-09 17:21 UTC (permalink / raw) To: Kees Cook; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: SIGSYS annoyance 2016-06-09 17:21 ` Andy Lutomirski @ 2016-06-10 9:08 ` Mikael Pettersson 0 siblings, 0 replies; 4+ messages in thread From: Mikael Pettersson @ 2016-06-10 9:08 UTC (permalink / raw) To: Andy Lutomirski; +Cc: Kees Cook, linux-kernel 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-06-10 9:09 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-06-04 5:16 SIGSYS annoyance Andy Lutomirski 2016-06-06 16:03 ` Kees Cook 2016-06-09 17:21 ` Andy Lutomirski 2016-06-10 9:08 ` Mikael Pettersson
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.