Date: Fri, 16 Jan 2004 14:00:56 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: arch@FreeBSD.org Subject: Signal delivery to kernel threads/processes? Message-ID: <Pine.NEB.3.96L.1040116135741.94620D-100000@fledge.watson.org>
next in thread | raw e-mail | index | archive | help
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@fledge.watson.org Senior Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1040116135741.94620D-100000>