> 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
>>>>> On Tue, 12 Feb 2002 11:15:54 +0000, David Howells <[email protected]> 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