WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Subject: Re: [Xen-devel] Creating a local network within the GuestOS and

To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: Subject: Re: [Xen-devel] Creating a local network within the GuestOS and r outing to an ext ernal network
From: Jeff Marshall <mars9050@xxxxxxxxxx>
Date: Thu, 19 Feb 2004 11:58:23 -0800
Delivery-date: Thu, 19 Feb 2004 23:50:50 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.5
>" Xen won't be able to enforce IP firewalling for you, but
>
>But this is a feature!   We want that external IP layer enforcement.
>For our purposes, full layer 2 network access by any domain is a bad
>thing.    

>Will this layer 2 switch supplant the current code, or be an addition?


I'd like to chime in at this point and bring up some issues that are important 
to me, but haven't been been raised yet.

While I agree that network-level filtering is an important part of a complete 
system, I'm not so sure that it belongs in the core, priveleged portion of 
xen. My reasoning is that if Xen is ever going to be analyzed either formally 
(i.e. using a specification or verifcation tool like spin, acl2, hol, etc.) 
or informally, that analysis will be significantly simpler if the portion of 
the system providing virtual machine (domain) separation does not include 
code for doing more complex filtering (i.e. anything more fine-grained than 
the existance of communications channels between domains) that could live
outside the VMM in a regular client domain where it can not interfere with the 
core code.

Switching / filtering based on MAC address seems (to me) to be a good place to 
draw the line because there would seem to be a one-to-one mapping between 
running virtual machines and virtual ethernet interfaces / adresses, whereas 
at the network level more complex mappings can and do occur (i.e. multiple 
ip's per VM, multiple VM's per ip). From a VMM perspective, what we want to  
control is the possibility of  interaction between VM's, not network-level 
entities which may or may not correspond to VM's.

This is, of course, my opinion. The Xen developers may be on a completely 
different page here, especially with regard to other issues (speed) that may 
conflict with the criteria of ease of analysis. I'd be curious to know if 
formal analysis is something that people are thinking about.

-Jeff Marshall


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel