[Top][All Lists]

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

Re: GSoC project about virtualization using Hurd mechanisms

From: zhengda
Subject: Re: GSoC project about virtualization using Hurd mechanisms
Date: Fri, 11 Apr 2008 10:50:22 +0200
User-agent: Thunderbird (X11/20080213)

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

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 :-)

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

reply via email to

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