GSoC: the plan for the project network virtualization

Hi everyone,

To implement the network virtualization, several pfinet servers must run at
the same time, and they must communicate with each other. Meanwhile, the
process on Hurd can choose its own pfinet server.

step 1. A mechanism for different pfinet servers to communicate with each
other:
There are two possible solutions to reach the goal at least: the BPF
translator and the hypervisor.
If it is done, it can also be used for subhurd.
BPF translator:
I wonder how the pfinet server tells the BPF translator?
Do we modify the code of pfinet to send the filter rule to BPF translator?
Hypervisor:
It shouldn't be difficult to make it work with subhurd.
When boot gets a open_device request from pfinet, return the port to the
hypervisor.

step 2. A mechanism for the user to run several pfinets together.
Do I need to use filesystem proxy to do it?
as I see, /servers/socket/1 is used for local, /servers/socket/2 is used for
inet.
Does it mean I can create /servers/socket/3 used for other pfinet?

step 3. override the default server in the system: using some approach
mentioned in the project of Server Mechanism.
Maybe I can try the first approach first.

I wonder how much work it could be?
And how do I start?

Best,
Zheng Da

Hi,

Sat, May 31, 2008 at 04:17:37PM +0200, Zheng Da wrote:

step 1. A mechanism for different pfinet servers to communicate with each
other:
There are two possible solutions to reach the goal at least: the BPF
translator and the hypervisor.

Right. You never followed up on the discussion which of the variants
best to persue This is actually a bit disappointing -- I was counting
on these questions being resolved before the beginning of the summer
session :-(

I wonder how the pfinet server tells the BPF translator? Do we modify
the code of pfinet to send the filter rule to BPF translator?

Yes.

step 2. A mechanism for the user to run several pfinets together. Do I
need to use filesystem proxy to do it?

No.

as I see, /servers/socket/1 is used for local, /servers/socket/2 is
used for inet. Does it mean I can create /servers/socket/3 used for
other pfinet?

No. These are for different protocol families.

/servers is for the default system servers. What you want to do is to
use private servers -- they are not supposed to be in /servers. You can
basically put them anywhere -- most likely in the home directory, or
perhaps somewhere in /var or in /tmp

There is really nothing special you need to do to be able to run
multiple pfinet:s. It's already possible right now -- there is just no
mechanism to tell a process to use an alternate server instead of the
default one (You could in fact do it using chroot, but that's a bit
of overkill :-) )

step 3. override the default server in the system: using some approach
mentioned in the project of Server Mechanism.
Maybe I can try the first approach first.

That's fine for the start.

I wonder how much work it could be? And how do I start?

Well, I must remind you that you were supposed to provide a schedule in
your application I accepted your not doing so, because the task
description was very unspecific, and you were not really in a position
to provide a schedule without discussing things first; but now that you
have an idea what you will be actually working on, you should be able to
come up with a rough schedule

I suggest you start with the server overriding mechanism, as it's the
easier part, and there is less to discuss

-antrik-

Hi,

Sat, Jun 07, 2008 at 10:12:21PM +0200, zhengda wrote:

1) hypervisor creates a virtual network interface

How is the programming interface like for the virtual network
interface? I mean, is the pfinet still able to open it with
device_open()?

Well, as I mentioned in the original discussion, both approaches are
possible: Either there is a special para-virtualized interface which
pfinets must explicitely implement so they can talk to the hypervisor.

the hypervisor provides a virtual network interface that looks just
like the actual Mach-provided one.

The first approach is simpler on the hypervisor side, but requires
changes in pfinet, and isn't fully transparent in usage.

Para-virtualization also can be more efficient -- but I'm not sure it
would make any difference here.

I personally think the fully virtualized approach is more elegant, but
YMMV.

If pfinet can open the interface with device_open(), I think we
need to write another program like boot to give pfinet the pseudo
master device port and help pfinet open the virtual network
interface.

Why another program? I'm pretty sure "boot" is the right place to handle
this.

The second question is: who can create the virtual network
interface?

By default, the user who invokes the hypervisor. (I.e. the one running
"boot".)

More sophisticated policy control is certainly possible, but I can't
think of any use case right now.

I still don't understand who should check and control the packet.

I'm not sure I understand the question. I thought it is rather clear
that the hypervisor does the checks?

-antrik-

Hi,
Here are my current problems:

1. How many pfinet servers are allowed to connect to one hypervisor?
If only one pfinet server is allowed to connect to one hypervisor,
hypervisors must communicate with each other to route packets sent
by pfinet servers.
If several pfinet servers are allowed to connect to the same
hypervisor, a hypervisor can route packets inside itself. If so,
does the hypervisor only route the packet among pfinet servers
that connect to the hypervisor?
If several pfinet servers are allowed to connect to the same
hypervisor, it's better for the hypervisor to create multiple
virtual network interfaces and each pfinet server can attach to
one interface. Maybe it can help to route packets among pfinet
servers.
2. Who can run the hypervisor and who can create the network interface?
The hypervisor should be able to access the real network
interface. I think only the priviledged user can run it.
Who can create the network interface depends on Problem 1.
3. How does the routing work?
it can always work if the packet is broadcasted to any pfinet
servers that connect to the hypervisor. then pfinet servers can
filter packets in the IP layer.
but it cannot give a good performance and there may be a security
problem: every user can see others' packets.
If no broadcasting, it's really difficult to do the routing.
The main reason is that IP isn't bound to the network interface
directly, and it's set in the pfinet server.
The hypervisor has no way to know which pfinet server has which IP
unless another function is provided for the pfinet to tell the
hypervisor what is its current IP.
4. How does the hypervisor guard the network traffic and filter
illegal packets?
It will be much work if the hypervisor understands all packets.

Best,
Zheng Da

zhengda wrote:
Hi,
Here are my current problems:
>
1. How many pfinet servers are allowed to connect to one hypervisor?
If only one pfinet server is allowed to connect to one hypervisor,
hypervisors must communicate with each other to route packets sent
by pfinet servers.
If several pfinet servers are allowed to connect to the same
hypervisor, a hypervisor can route packets inside itself. If so,
does the hypervisor only route the packet among pfinet servers
that connect to the hypervisor?
If several pfinet servers are allowed to connect to the same
hypervisor, it's better for the hypervisor to create multiple
virtual network interfaces and each pfinet server can attach to
one interface. Maybe it can help to route packets among pfinet
servers.
2. Who can run the hypervisor and who can create the network interface?
The hypervisor should be able to access the real network
interface. I think only the priviledged user can run it.
Who can create the network interface depends on Problem 1.
3. How does the routing work?
it can always work if the packet is broadcasted to any pfinet
servers that connect to the hypervisor. then pfinet servers can
filter packets in the IP layer.
but it cannot give a good performance and there may be a security
problem: every user can see others' packets.
If no broadcasting, it's really difficult to do the routing.
The main reason is that IP isn't bound to the network interface
directly, and it's set in the pfinet server.
The hypervisor has no way to know which pfinet server has which IP
unless another function is provided for the pfinet to tell the
hypervisor what is its current IP.
4. How does the hypervisor guard the network traffic and filter
illegal packets?
It will be much work if the hypervisor understands all packets.
>
Best,
Zheng Da
>
Hi,

I'm thinking about the packet routing in the hypervisor.
I suppose a hypervisor can have several virtual network interface at the
same time.
1. solution is that the hypervisor broadcasts a packet to every
pfinet server, as I said before.
2. The hypervisor can always track which packet is from which virtual
network interface.
and a table can be built to record which interface has what IP.
It sends a packet to the interface who owns the destination IP.
The first solution can be seen as a hub, and the second one as a switch.
I don't like the second one. It's too complex, and there is no reason to
make the hypervisor so complex.

An acceptable solution (at least for me) can be:
when a virtual network interface is created, a network address must be
bound with it,
so the hypervisor can know where to send the packet.
We can think the network address tells the network that the interface
connects to.
The user should also tell the hypervisor what is the network address of
the external network,
so the hypervisor can know when to send the packet to the external network.
It's reasonable to do that because the real network interface also
connects to the network with a fixed network address.
We can suppose that the interfaces bound with the same network address
are in the same sub-net.

Anyway, my current implementation can be that
there is only one interface in the hypervisor,
and all pfinet servers connect to the same interface,
so every server should get one copy.

Best,
Zheng Da

Hi,

Mon, Jun 30, 2008 at 04:44:36PM +0200, zhengda wrote:

I said the multiplexer (or the hypervisor, I'm not very sensitive to
the name:-) can have multiple interfaces and there was a "filter"
behind every interface. The filter here actually means the BPF
implementation (maybe this confused you). But I didn't think about
who gave the filter rules.

Ah, I see. So there was some confusion between the (optionally)
optimized internal implementation, and how it appears to the outside

At the beginning, I thought the rules associated with an interface
could apply to all clients connected to the interface, so the rules
might be from the user who creates the interface. But as you said,
every client can give its own rules and the rule can be from the
pfinet server and even the filter translator.

Right.

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.

-antrik-