Signal delivery to kernel threads/processes?

[Robert Watson]

Bill Paul raised an interesting question with me recently -- he observed
that a userspace process running with root privileges could deliver a
signal to a kthread, and that this might produce undesired behavior.  I
was sure that, at some point, we had a check disallowing this, but I don't
see it in either RELENG_4 or HEAD.  Do we rely on the ability to
send/receive signals to interrupt kthreads, that we know of?  While the
signal delivery itself doesn't make sense, waking up a tsleep() with
PCATCH could well be useful behavior.  Should a kthread have to declare if
it wants to receive interruptions?  Given plans, at some point, to make
kthreads be real threads, and be part of a kernel process, that would
raise some challenges for code relying on the ability to be interrupted
with a signal in kernel space, as signals generated by kill() are
targetted at processes, not threads.

Any thoughts?  It's tempting simply to add the following to cr_cansignal()
to at least disallow sourcing the signals in userspace:

	if (p->p_flag & P_SYSTEM)
		return (EPERM);

But I don't have a broad enough view of what goes on in the kernel to
reason about what disasters this might cause if signalling is relied on. 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert at fledge.watson.org      Senior Research Scientist, McAfee Research