bug-hurd
[Top][All Lists]
Advanced

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

Re: GSoC: the plan for the project network virtualization


From: zhengda
Subject: Re: GSoC: the plan for the project network virtualization
Date: Fri, 04 Jul 2008 00:24:56 +0200
User-agent: Thunderbird 2.0.0.14 (X11/20080421)

olafBuddenhagen@gmx.net wrote:
Note however that making the multiplexer handle rules both from the
clients and from filter translators is not trivial. It requires figuring
out how to merge rules correctly; it requires making sure that the
client can never override rules set by the filter translator.

That's why I suggest leaving this optimization for a later step;
initially having the filter translator run its own BPF implementation,
and the multiplexer only handle the client rules. So the filter and the
multiplexer are really seperate, not only in function, but also in
implementation.
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.

the filter translator actually doesn't have to be used with the multiplexer in every case. We use it only for enforcing policies. 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. so maybe the performance of the filter translator isn't that important.

> "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. 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.

Best,
Zheng Da




reply via email to

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