Re: PATCH: proc_do_stop and rpctrace

[Roland McGrath]

> Actually, according to some helpful soul (hi Jeroen), it works just fine.
> Which makes sense, because the port for foo and whatever else comes from the
> filesystem, and rpctrace rewrites it in both directions, first when it comes
> in.

Of course!  Duh.

> The problem is with ports that are rewritten the first time when the come
> out, but are actually ports that come from the outside and have never been
> seen by rpctrace before.  The task and thread ports come to mind, because
> they are gotten by system calls in the task.

This is not actually the issue.

> The only way to properly fix it seems to somehow provide the task with
> a replacement task port to be used instead of mach_task_self, which requires
> support in the task (ie glibc).  Which would mean all RPCs, even
> mach_task_deallocate etc, would go through rpctrace (not really a performance
> boost :).

This is already what happens.  There is no need for the traced task to know
about it (that would be an inherent limitation fundamentally changing the
nature of what we mean by "interposition").  mach_task_self just returns
one of the task_special_port rights, which can be reset.  See
rpctrace.c:traced_spawn.  It's from this root that all the traced ports are
found.

The issue is things outside the tracing domain, i.e. proc.  But this is
only an issue because rpctrace lets a port through without unwrapping it
first.  In fact, rpctrace already intends to do the right unwrapping, but
it doesn't do it because it hasn't wrapped the thread port to begin with.

rpctrace really ought to be wrapping the thread control ports as it does
the task port.  There is a thread_set_special_port that can do this in just
the same way.  The problem is that it is not aware of threads being
created.  I think the same problem exists with newly-created tasks.  The
task port from a task_create and the thread port from a thread_create get
traced like other ports and so rpctrace sees the messages sent by the exec
server and so forth.  But once the new task does mach_task_self, it gets
its own real port and rpctrace is out of the picture.

rpctrace needs to grok task_create and thread_create reply messages
specially and no only wrap those ports, but perform set_special_port on
them.  A kludge would be to grok those msgids and assume they are right.
Another approach is to maintain for each traced port whether we think it is
a task, a thread, or something else, and for send-once rights if they are
the reply port for a task_create or thread_create or not.  Starting out
with the task port, you know it is a task.  If a task gets a task_create
message, the reply port is a task_create reply port; if a task gets a
thread_create message, the reply port is a thread_create reply port.  If
one of those special reply port gets its corresponding reply message ID,
the port therein is a task/thread port and rpctrace tweaks it.  This plan
won't catch task or thread ports that are passed in to a traced program and
start tracing them, but that's probably not something you want anyway
(e.g. if you are tracing proc, then you might not want tracing proc_dostop
to make you start tracing that thread).

rpctrace doesn't yet support "attach" anyway, but if it did then it would
need to not just interpose on the live task port, but find all its threads
and interpose on their thread ports individually.