linux-kernel - Re: SIGSYS annoyance

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 6 Jun 2016 09:03:25 -0700
From:	Kees Cook <keescook@...omium.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: SIGSYS annoyance

On Fri, Jun 3, 2016 at 10:16 PM, Andy Lutomirski <luto@...capital.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