Re: Hacking gnumach to track parental relationship of tasks

[Ludovic Courtès]

Justus Winter <4winter@informatik.uni-hamburg.de> skribis:

> Quoting Ludovic =?utf-8?Q?Court=C3=A8s?= (2013-09-10 20:00:32)
>> Justus Winter <4winter@informatik.uni-hamburg.de> skribis:
>> 
>> > Quoting Samuel Thibault (2013-09-09 19:40:23)
>> >> Ludovic Courtès, le Mon 09 Sep 2013 18:48:03 +0200, a écrit :
>> >> > Samuel Thibault <samuel.thibault@gnu.org> skribis:
>> >> > > Ludovic Courtès, le Sat 07 Sep 2013 22:04:06 +0200, a écrit :
>> >> > >> However, wouldn’t it be preferable to fix it by interposing on
>> >> > >> ‘task_create’ calls, à la clans & chiefs?  (IIUC, this can be done 
>> >> > >> with
>> >> > >> by setting the TASK_KERNEL_PORT of a task.)
>> >> > >
>> >> > > Apparently task_create is a kernel trap.
>> >> > 
>> >> > Isn’t rpctrace able to interpose on it?
>> >> 
>> >> I don't think there is any way to interpose a trap.
>> >> 
>> >> It probably happens that libc nicely uses the RPC, but nothing prevents
>> >> a process from raising a trap.
>> >
>> > As I understand [0] one can interpose all Mach system calls
>> 
>> Yes, and ‘task_create’ is no exception to the rule:
>> 
>> --8<---------------cut here---------------start------------->8---
>> ludo@darnassus:~$ rpctrace -o ,,s sh -c 'sleep 2 & true'
>
> This is all very fascinating, but completely unrelated. Have you
> looked at [0]? Have you looked at rpctrace?

(Please let’s keep the tone cordial, we’re both trying to be
constructive, I think.)

I was not referring to syscall emulation, but to ‘task_set_special_port’
with the TASK_KERNEL_PORT flag, which is how rpctrace interposes on all
RPCs including those normally served by the kernel, IIUC.

>> So what about using that technique to achieve what you want?  :-)
>
> Besides me having second thoughts about using this on every process on
> the system (this is the part of my message that you conveniently left
> out while quoting btw)?

You wrote:

  Then again, I do not think it is meant as a mechanism to change the
  semantic of one system call for all processes and I do not know the
  performance implications of this mechanism.

In the case we discuss here, the semantics of ‘task_create’ would be
preserved.

There’s surely a performance impact, that would have to be measured.
Now, how bad is it compared to, say, calling user-space ethernet drivers
vs. in-kernel drivers?  :-)

> Well, if anyone can set the emulation vector, how do you prevent any
> process from clearing your interception function? By intercepting the
> setting of the emulation vector and replicating the emulation
> yourself?

Yes, or just by making it a no-op, no?

(I think the problem also arises with the patch your proposed, no?)

Thanks,
Ludo’.