Re: GSoC project about virtualization using Hurd mechanisms

[olafBuddenhagen]

Hi,

On Thu, Apr 10, 2008 at 02:14:06PM +0200, zhengda wrote:

> What I mean is the mechanism provided by the packet filter provides us
> a  possible solution. I don't expect it works now:-)

I see :-)

> As I can see, ether_filter in pfinet is hard coded. I think it's
> better  to allow the user to set up the filter according to their own
> requirement. The communication between two pfinet may work by changing
> ether_filter.

Not really. The filter is only responsible for making sure that pfinet
gets packets destined for the IP it handles. I don't see any reason why
a user would want to change it -- it's intimately bound to the
functionality of pfinet, and probably doesn't make sense to change
without changing other parts of pfinet as well...

> By the way, gnumach provides BPF and MPF. But pfinet seems to use MPF?
> but why is BPF also provided?

MPF is the original Mach Solution; BPF was added later AFAIK. IIRC
Richard Braun (syn), who was working on the packet filter improvements,
said that BPF is more common and more powerful...

But that reminds me that filtering outgoing packages only works with BPF
IIRC. So we would have to swith pfinet to use BPF for that...

Part of the original plan was to create a BPF translator, so pfinet (and
other potential users) would talk to this translator, rather than
directly to the kernel. However, that work was never completed :-(
Ideally, the BPF translator should be finished, and pfinet ported to
that...

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

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.

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-