To: davidm@hpl.hp.com
Cc: David Howells <dhowells@redhat.com>, torvalds@transmeta.com,
        linux-kernel@vger.kernel.org
Subject: Task ornaments
In-Reply-To: Message from David Mosberger <davidm@hpl.hp.com> 
   of "Mon, 11 Feb 2002 16:13:07 PST." <15464.24083.54161.609609@napali.hpl.hp.com> 
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.1
 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 12 Feb 2002 11:15:54 +0000
Message-ID: <23542.1013512554@warthog.cambridge.redhat.com>
From: David Howells <dhowells@redhat.com>
Sender: linux-kernel-owner@vger.kernel.org


> Is the idea that only kernel modules can install ornaments?  If so,
> security shouldn't be a major issue.

Only kernel space can install ornaments. Userspace must ask kernel space to do
so indirectly. For instance, with my ornament-based process tracing that I'm
writing, userspace happens to string an ornament onto the traced process when
it invokes the attach-to-process operation provided, and the conditions under
which it does this are carefully controlled.

> I do have stability concerns, however: callback mechanisms always work
> great until they really start to get used.  When that happens, you
> invariably run into very nasty ordering issues (just witness the
> recent initcall issues, and that was an easy case!).

Well, I've been using them in two ways to date, without much of a problem. The
biggest problem I've seen is with signal cancellation/alteration by the signal
delivery callback on an ornament, since that affects what signal (and if) the
next ornament sees.

There is also the problem of what happens when the signal delivery callback
function wants to sleep (for instance, if the ptrace handler wants to consult
the debugger). I think I've got that one solved too: signal delivery is
suspended until all the ornaments have been notified (all other operations are
synchronous). If someone sleeps during the notification callback, they have to
awaken on SIGKILL, but not anything else.

I also make sure I can't get into an endless iteration loop due to a task
ornament constantly removing itself from the list when it is notified and then
adding itself again by putting it back in the list in an ordered fashion.

> My other concern is performance: I have a suspicion that we'll start
> out with a handful of callbacks and over time more and more callbacks
> will be added.  This can quickly add up to real overhead.

I don't see there being much need for more callbacks. There isn't much else to
get notification for. The heaviest addition is notification of userspace
resumption, but I restructured entry.S to permit this flag in a way that cost
as little as possible. All the other callbacks are in infrequently used paths
(fork/clone, exeve, exit) or (in theory) entirely replace existing chunks of
code (signal delivery, syscall tracing).

There are two further callbacks I have thought about adding:

 (1) Subsumation of the pending signal-notifier stuff currently in the
     task_struct (used by DRM). However, this means the the sigmask_lock must
     be held any time you want to walk or change the task ornament list:-/

 (2) CPU user exception notification(s). Give task ornaments a chance to
     handle these in a way more appropriate to the binfmt or personality of
     the process (for instance, to generate a Win32 structured exception).

     However, I think this is probably superfluous given the provision of
     the signal delivery notification.

There are also a number of other things I've thought about trying to do with
task ornaments, though I'm not sure of how practical they are. The only one I
can actually think of at the moment, though, is:

 (1) Child process notifying parent (and other processes) on death (basically
     the SIGCHLD handler). This would allow this bit of code to be removed
     from the exit path. A parent process would install an ornament in each
     child process's list and would remove them when the parent died. This
     might make thread handling somewhat easier, as signals could then be
     easily redirected.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/