Re: GSoC project about virtualization using Hurd mechanisms

[zhengda]

olafBuddenhagen@gmx.net wrote:
> > And why do you not think it's an elegant solution?
> >     
>
> Well, I generally dislike the idea of the packet filter in the kernel...
> On one Hand, it is convenient that you can run multiple systems in
> parallel (e.g. subhurds), and they don't need to know about each other
> at all; the only thing they have in common is the kernel. On the other
> hand, it doesn't really fit the microkernel philosophy: The
> functionality is limited and not modifiable without hacking the
> kernel...
>
> One consequence is that there is no policy what kind of filters a
> process can set -- any process that has the necessary permissions to
> access the device, can do anything it desires. When talking about the
> limitations of subhurds, I think I mentioned that device sharing is
> possible for hard disks and network interfaces, but the sharing is not
> safe -- now you know why.
>   
I have a question: why is it not safe for two pfinets to share one device?
the communication between the device driver and pfinet is IPC.
As long as IPC communication is safe, the device driver should be able 
to get all packets from pfinets,
and pfinets should be able to get the packets dispatched by the driver.
> Fixing this would be part of the "improve subhurds" task, and it would
> involve writing a network server that acts as superviser, enforcing
> access policies for the subhurd. It would complicate subhurd startup a
> bit, but would make subhurds more useful...
>
> The BPF translator would be kind of a middle ground: It would leave tha
> actual packet filter in the kernel, but move the access to it outside.
> (And thus allow enforcing policies.) However, in a simple setup, only
> multiple servers running in a single Hurd instance would share the
> translator; other instances (subhurds) would still have their own
> server, and thus no policy would be enforced.
>   
Every pfinet or other users talk to the BPF translator first,
Does it mean only the BPF translator can talk to the network driver 
directly?
The other problem is who gives the filter rule.
If it's pfinet, the filter rule of every pfinet should be sent to the 
translator first?
But the current filter rules in pfinet is hard coded, so
no matter how many filters are in the packet filter in the kernel, the 
result is the same,
the packet filter cannot help the BPF translator dispatch packets.
If the BPF translator deicdes the filter rules for every pfinet, I still 
haven't found
a simple way for the translator to dispatch packets.
I think I'm quite confused by the BPF translator.
Could you give me more detailed information?
> It would be possible to force the subhurd to use the main Hurd's BPF
> translator. However, that would require some mechanism to allow a
> subhurd to access another Hurd's translators -- this could also be part
> of the "improve subhurds" task. It's much more complicated though than
> implementing a low-level server (supervisor), which could use a simpler
> interface, or even be completely transparent to the clients...
> (Pretending that it's the actual kernel device.)
>   
> So you see, there are many options :-)
>
> -antrik-
>   
The other question is: do we need to consider about the issue of the 
performance
since the packet goes between the kernel and the user space so many times.
I still have some questions about the supervisor,
but it's better for me to understand the idea behind the BPF translator 
first:-)

Zheng Da