[EMAIL PROTECTED] wrote:
"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.
Do you mean something like a translator who open the network interface,
and returns the port of the network interface to the socket server such
as pfinet?
If you mean keeping the original idea of a hypervisor that does provide
several virtual interfaces *and* enforces policies on each, then no,
this is not more flexible. It is a monolithic beast combining different,
mostly unrelated functionalities. It is un-hurdish; and it can never be
more flexible than individual components that can be combined as
necessary.
I agree.
The only disadvantage of separate components is that the packets may
need to traverse more servers before they arrive. But, as explained on
IRC, this probably could be optimized with some BPF magic, if it turns
out to be a serious problem.
Last time on IRC, if I understand it correctly, you said the
optimization is to make all packets go through the kernel, and the
kernel dispatches the packet with the BPF. Now the multiplexer actually
works just as the multiplexer (if the part for the network IO in the
kernel can be called a multiplexer) except the filtering function is
separated. I really don't think it's necessary to make the packet to go
through the kernel. But if the multiplexer is responsible to dispatch
the packet, I think we go to the original idea (the hypervisor).
By the way, is it possible to provide a mechanism that allows two
components to only share the virtual memory (the user of the components
can make the choice: to share the memory or not)? maybe it's a bit like
the clone with the flag of CLONE_VM in Linux. If it's possible, I think
it can much improve the performance issue above. But it's just my
imagination.
Best,
Zheng Da