On Wed, Feb 22, 2012 at 5:06 PM, H. Peter Anvin <hpa@xxxxxxxxx> 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 linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
