From owner-freebsd-arch@FreeBSD.ORG Fri Jan 16 11:03:13 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1384A16A4CE for ; Fri, 16 Jan 2004 11:03:13 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1A6C43D1D for ; Fri, 16 Jan 2004 11:02:43 -0800 (PST) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.10/8.12.10) with ESMTP id i0GJ0uUd095312 for ; Fri, 16 Jan 2004 14:00:56 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i0GJ0umE095309 for ; Fri, 16 Jan 2004 14:00:56 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 16 Jan 2004 14:00:56 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: arch@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Signal delivery to kernel threads/processes? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jan 2004 19:03:13 -0000 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