Re: looking for the solution of rootless subhurd

[olafBuddenhagen]

Hi,

On Tue, Dec 09, 2008 at 12:30:08AM +0000, Da Zheng wrote:

> The function add_tasks (proc/mgt.c) gets all tasks in the host by
> calling host_processor_sets(), host_processor_set_priv() and
> processor_set_tasks() because the process server needs to check if the
> port is a task port or not.

I don't understand.

> Obviously, the process server in the subhurd cannot get all tasks in
> the  host. Instead, it should only get the tasks that belong to the
> subhurd.

Actually, in the current subhurd implementation, the subhurd does see
all host tasks as well... Only it doesn't know much about them, as they
are not registered with the subhurd's proc.

Of course, ideally we would hide them; but it doesn't seem terribly
important, and in most situations probably isn't worth the performance
hit...

Perhaps it could be made optional. But unless it can be implemented with
little effort, I suggest not spending any time on it.

> I am thinking of a way to trace tasks in subhurd.
>
> One way I can think of is that boot creates a proxy for the RPC
> task_create. As a result, boot needs to create pseudo task ports for
> all  tasks in subhurd and run as a proxy for all RPCs on the task
> port. Extra  RPCs are needed for the tasks to get the pseudo task
> ports, and  mach_task_self() in glibc need to be modified.
>
> This solution should be powerful enough (it can solve all problems I
> have got so far) as long as all programs in subhurd uses the modified
> mach_task_self() in glibc. But it has two drawback:

> 1. There isn't an effective way to prevent the programs in subhurd
> calling the system trap mach_task_self(). If the program does use the
> system trap, it might not have the right behavior, but at least it
> doesn't harm the tasks in main Hurd and other subhurds.

> 2. It seems a bit heavy. Almost all of RPCs to the kernel are
> redirected  to the boot.
>
> Anyone has comments for the solution I suggested above? I hope there
> is an easier way in Mach/Hurd to trace tasks.

Well, I have a feeling that we are missing something here. If such
fundamental system calls as mach_task_self() can not be virtualized,
what's the point in making any system calls virtualizable? Surely that's
not how the Mach designers intended it...

But I really have no clue what we could be missing.

-antrik-