|
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:
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.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.
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.
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.> "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 deviceport, which would forward open() on the network device, but block all others.
Best, Zheng Da
[Prev in Thread] | Current Thread | [Next in Thread] |