[Top][All Lists]

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

Re: GSoC project about virtualization using Hurd mechanisms

From: olafBuddenhagen
Subject: Re: GSoC project about virtualization using Hurd mechanisms
Date: Tue, 15 Apr 2008 08:48:26 +0200
User-agent: Mutt/1.5.17+20080114 (2008-01-14)


On Sun, Apr 13, 2008 at 11:53:51PM +0200, zhengda wrote:

> As my understanding, the role of the BPF translator is to work as a
> guard between the user and the packet filter in the kernel.


As I said, I'm not sure whether it was originally meant as a guard, or
only for convenience... But it could be used as guard I believe.

> Does this mean that only root user can run pfinet in the Hurd?

Yes, only root gets access to privileged ports.

> But it makes sense. Now I know why currently only root can run
> subhurd.

Indeed. A subhurd currently is just a second complete Hurd instance,
quite equal in almost all regards to the main instance. (Thus the name
"neighbor Hurd" is actually more precise...)

Only root can provide the necessary privileged ports when booting the

The solution is to make it possible for the subhurd to run without the
privileged ports -- either by implementing proxies that behave just like
the real privileged ports, except that their actions are limited by what
the user running them has access to; or by implementing a special
interface for vitualized devices, which the guest system can handle
explicitely (para-virtualization).

> How does the network supervisor work? Is it similar to the second
> solution I have mentioned (every pfinet has  to send packets to a
> central process first which helps forward them)?


> And why is the network supervisor implemented easily than the BPF
> translator for helping subhurd communicate with the main Hurd? I mean
> since subhurd can communicate with the supervisor, why can it not
> communicate with the BPF translator of the main Hurd in the same way?

Well, for one -- as I said -- the hypervisor could be completely
transparent, just emulating the "real" device, so the subhurd doesn't
even know it's not talking to the kernel. This is more complicated on
the hypervisor side, but has the advantage of requiring no modifications
in the guest system using it.

But I initially thought even in the para-virtualized case, where the
system is modified to talk to a special device with an explicitely
virtual interface rather than something looking like the kernel device,
an indepentant hypervisor still could be easier than a normal
translator, because it can offer an interface that is explicitely meant
to be used by independant systems...

However, thinking a bit more about it, I realize that this notion was
probably wrong. What make translators tricky is the lookup and
authentication stuff. But the subhurd will get a port ready for use
(authenticated against the user running the subhurd). And once you have
the actual port, a translator can implement any kind of interface it
likes -- it could actually be the very same interface that a standalone
hypervisor would have!

So unless I am missing something important now, my previous statement
was false. Having the hypervisor (or the BPF server) implemented as a
translator should not make things more complicated in any way :-)


reply via email to

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