[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Signal delivery to kernel threads/processes?
- Subject: Signal delivery to kernel threads/processes?
- From: rwatson at FreeBSD.org (Robert Watson)
- Date: Fri Jan 16 11:04:39 2004
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)
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_(_dot_)_watson_(_dot_)_org Senior Research Scientist, McAfee Research