netdev - Re: [PATCH v10 07/11] signal, x86: add SIGSYS info and make it synchronous.

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]

Message-ID: <CAB=4xhqndEw3tMPaUcdZh_jcjQcoK_=7GwOc5gVhnz5o_4eWzQ@mail.gmail.com>
Date:	Thu, 23 Feb 2012 09:38:57 -0800
From:	Roland McGrath <mcgrathr@...gle.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Kees Cook <keescook@...omium.org>, Will Drewry <wad@...omium.org>,
	Andrew Lutomirski <luto@....edu>,
	Indan Zupancic <indan@....nu>, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org, linux-doc@...r.kernel.org,
	kernel-hardening@...ts.openwall.com, netdev@...r.kernel.org,
	x86@...nel.org, arnd@...db.de, davem@...emloft.net,
	mingo@...hat.com, oleg@...hat.com, peterz@...radead.org,
	rdunlap@...otime.net, tglx@...utronix.de, eparis@...hat.com,
	serge.hallyn@...onical.com, djm@...drot.org, scarybeasts@...il.com,
	pmoore@...hat.com, akpm@...ux-foundation.org, corbet@....net,
	eric.dumazet@...il.com, markus@...omium.org
Subject: Re: [PATCH v10 07/11] signal, x86: add SIGSYS info and make it synchronous.

On Wed, Feb 22, 2012 at 5:06 PM, H. Peter Anvin <hpa@...or.com> wrote:
> I meant whether or not a signal can be blocked/caught and the fact that
> the signal exists at all.
>
> Now I guess we could have "blockable" and "unblockable" SIGSYS, but that
> would seem to have its own set of issues...

Oh.  I certainly don't think we should ever add any new signals to the set
that cannot be caught, blocked, or ignored.  That has been just SIGKILL and
SIGSTOP since 4.2BSD, which first introduced the modern concept of blocking
signals.  There are lots of reasons not to change that, which I won't go
into unless someone really wants me to.

However, I don't think there is anything really wrong with having certain
cases that generate a signal and at the same time unblock it and reset it
to SIG_DFL.  That's just an implementation detail of a policy of "dump core
right now, no other option".  (Conversely, directly calling do_exit won't
ever dump core, though it can be made to look signalesque to the parent and
tracers.)

For seccomp-filter, I personally don't see any problem with simply
generating SIGSYS in the normal way (and aborting the syscall, of course).
If someone wants to ensure that SIGSYS is never caught or blocked, they can
just do that by having a filter that doesn't allow it to be caught or
blocked (and of course make sure to reset its inherited state).  It is a
bit tricky to cover all the ways, since it's not just sigaction and
sigprocmask but also sigreturn, where the blocked signal set to be restored
is in a slightly arcane location--but it ain't rocket science.

But I don't really have any strong opinion about what seccomp-filter should
do.  (Though it does seem worthwhile not to rule out the possibility of
dumping core on a policy violation, since that will be useful for people to
debug their code.)

Thanks,
Roland
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html