Re: GSoC: the plan for the project network virtualization

[olafBuddenhagen]

Hi,

On Fri, Jul 04, 2008 at 12:24:56AM +0200, zhengda wrote:
> olafBuddenhagen@gmx.net wrote:

> So if I'm right, the filter translator has to implement the RPC in
> device.defs to communicate with the client and it calls the RPC to
> communicate with the multiplexer.

Yes. The filter simply proxies the interface it is attached to.

> the filter translator actually doesn't have to be used with the
> multiplexer in every case. We use it only for enforcing policies.

Exactly.

> The  only situation I think it can be used is that a user's
> multiplexer or a  pfinet server opens a virtual network interface
> created by the root's  multiplexer (so the user's multiplexer can
> access the external network).  The filter translator doesn't need to
> sit on the user's multiplexer.

Well, depends on the use case. The user might want to enforce policies
on his own clients, too.

>>> > "root could delegate access to the real network interface, and the
>>> > user  could run a hypervisor"? How do we do it? create another
>>> > program that is run by root and that  communicates with the
>>> > hypervisor?
>>
>> To be honest, I don't know the details. In a capability system, it
>> should always be trivial to delegate access to something. But I do
>> fear that the Mach device interface does not really fit there -- that
>> it's not possible to directly hand out a capability for a single
>> kernel device. If that is the case, we would again need a proxy for
>> the master device port, which would forward open() on the network
>> device, but block all others.

> If a proxy can help the user's multiplexer open the network interface,
> I  wonder who can control the traffic from the user's multiplexer.

Mind the context: I was talking here about the specific case where root
wants to give the user full access to a real network interface.

In other cases, where more limited access is desired, root would set a
filter of course.

Admittedly, giving full access can be considered a special case of
giving limited access -- namely with an all-pass filter... But that's
not very efficient :-) (At least in the simple implementation.)

> I think it's better to run a multiplexer by the root on the real
> network  interface and the traffic control is done by the filter
> translator  running on the virtual interface provided by the root's
> multiplexer.

Note that it's not strictly necessary for root to run a multiplexer. To
enforce policies, it is sufficient to set the filters directly on the
real network interface. The multiplexer is necessary only to allow
routing between different clients...

-antrik-