Re: SIGSYS annoyance
Andy Lutomirski writes: > On Mon, Jun 6, 2016 at 9:03 AM, Kees Cook wrote: > > On Fri, Jun 3, 2016 at 10:16 PM, Andy Lutomirski > > 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.
Re: SIGSYS annoyance
On Mon, Jun 6, 2016 at 9:03 AM, Kees Cook wrote: > On Fri, Jun 3, 2016 at 10:16 PM, Andy Lutomirski 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
Re: SIGSYS annoyance
On Fri, Jun 3, 2016 at 10:16 PM, Andy Lutomirski 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
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.
