[<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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
