[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PATCH: proc_do_stop and rpctrace

From: Marcus Brinkmann
Subject: Re: PATCH: proc_do_stop and rpctrace
Date: Sat, 16 Aug 2003 15:03:09 +0200
User-agent: Mutt/1.5.4i

On Sat, Aug 16, 2003 at 03:58:34PM +0300, Ognyan Kulev wrote:
> This is exactly what I meant, but I haven't looked deep enough.  This 
> user-supplied task_t is added through proc/mgt.c:add_tasks (called from 
> proc/hash.c:task_find, called from proc/mgt.c:S_proc_child).  But 
> add_tasks retrieves microkernel's task list and searches for this 
> particular task.  So user can't promote his own port as task port to the 
> proc server.  So what I said is plain wrong, and just propaganda ;-)

Ah, good.  I stopped dead at the add_task and didn't bother to look up what
it does ;)
> One possible solution is rpctrace not to masquarade system ports, like 
> thread ports, and the patch to be reverted.  For example, on each traced 
> mach_msg, the list of task's threads can be retrieved.  This will allow 
> not masquarading thread ports when they are passed through mach_msg.  It 
> will slow the whole tracing, but at least it will circumvent this 
> particular problem.

This is one option I just sent in a mail to hurd-devel.  The other option
which is slightly cleaner is to provide the task with a wrapped task and
thread port, and in consequence also wrap other thread ports, and have
support in glibc that it uses these ports instead mach_task_self and
mach_thread_self.  Which is also a performance hit, because now RPC trace
gets to see almost all RPCs, including those on local ports.


`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus@gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]