Task ornaments

Task ornaments

[David Howells]

> 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

Re: Task ornaments

[David Mosberger]

>>>>> On Tue, 12 Feb 2002 11:15:54 +0000, David Howells <dhowells@redhat.com> said:

  David.H> Well, I've been using them in two ways to date, without
  David.H> much of a problem.

Well, that's my point.  This kind of stuff works great until you
start to really push it.

  David.H> The biggest problem I've seen is with
  David.H> signal cancellation/alteration by the signal delivery
  David.H> callback on an ornament, since that affects what signal
  David.H> (and if) the next ornament sees.

Yup.  And that's only the beginning.  I bet the perfmon support would
introduce even more interesting ordering constraints.

  David.H> There are two further callbacks I have thought about
  David.H> adding:

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

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

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

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

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

Basically, you're proving my point.  Ornaments look like a generic
facility, yet there are global dependencies (ordering, locking, ...)
which require each use to be checked against possibly all existing
ornament users.

	--david