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

On Wed, Feb 22, 2012 at 6:29 PM, H. Peter Anvin [off-list ref] wrote:

On 02/22/2012 04:08 PM, Kees Cook wrote:

quoted

quoted

Hrm, it might be possible to do_exit(SIGSYS) which would be both. It
looks like tsk->exit_code would be SIGSYS then, but I'll look a little
more closely to see what that'll actually do.

As long as there's no way it can get blocked, I'd be fine with that.
It would, actually, be better than SIGKILL because, as Andy said, it's
more distinguishable from other situations. I've long wanted a signal
to be used for "violated policy" that wasn't just a straight SIGKILL.

Can we really introduce force-kill semantics for a POSIX-defined signal?
 Other user space programs might use it for other purposes.

I'm wondering if the right thing may be to introduce some variant of
exit() which can return more information about a signal, including some
kind of cause code for SIGKILL?

While it'd be harder to send back extra info, passing SIGSYS to
do_exit() should result in the si_status for the emitted SIGCHLD to be
SIGSYS (si_status = (tsk->exit_code & 0x7f)).  I think it'll still
have a si_code of CLD_KILLED, but it'd be enough for a parent to
differentiate the task-death path.  I'll try it out before I post
another patch rev.

A variant that allowed extended exit information would be useful
(especially for this patch series), I'm not sure I'd know where to
start.

cheers!
will