Xen devel - Feb 2004 - Subject: Re: Creating a local network within the GuestOS and r outing to an ext ernal network

>" 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> 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.
Then you''ll be happy to here that this functionality is moving
outside Xen and into a ''driver domain'' in the new IO model.
 
> 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''m confident we can move this functionality into driver domains
without loosing much performance. Stay tuned.
> I''d be curious to know if formal analysis is something that
> people are thinking about.
I''d love to see this happen, but I think even the complexity of
something simple like Xen is beyond what current verification
tools can cope with. In the meantime, I think if we just stare at
the code really hard...

Ian


-------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Hi!

Ian Pratt wrote:
>>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.
> 
> 
> Then you''ll be happy to here that this functionality is moving
> outside Xen and into a ''driver domain'' in the new IO
model.
>  
Do you mean that (in a very simple view) Xen will take care of memory 
and domain management and another domain (domain 0?) will take care of 
every other piece of hardware like IDE, SCSI and NICs?

This would be very cool but, as I understand. Xen requires "hardware" 
drivers to be event based, so the guest OS in domain 0 would need a 
giant patch... Right?

And Xen will end up with a) the Xen core, b) "hardware domain" guest
OS
patch and c) general guest patches. Now we have a) and c), only... :-)

Making the core small is very good, but enlarging the rest - the
"guest"
universe - is not so good...

Maybe I didn''t understand your sentence :-) Can you explain a bit more,
please? :-)

Thanks,
Nuno Silva


-------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> Do you mean that (in a very simple view) Xen will take care of memory 
> and domain management and another domain (domain 0?) will take care of 
> every other piece of hardware like IDE, SCSI and NICs?
There''ll be a concept of ''driver domains'', each one
of which can
take care of one or more devices. As well as running the
hardware, they''ll handle the secure virtualization of the device
to domains. They only contain soft state, so if a device driver
fails it can just be re-instantiated (assuming it hasn''t
managed to irrecoverably wedge the hardware or DMA all over
memory, but such faults are relatively rare...)
 
> This would be very cool but, as I understand. Xen requires
"hardware"
> drivers to be event based, so the guest OS in domain 0 would need a 
> giant patch... Right?
To enable us to use Linux drivers, the device driver domains will
be based on a cut-down version of xenolinux with all the
unnecessary stuff compiled out (most driver domains will have no
need for file systems, network stacks, character devices etc).
These domains will need additional code to do the device
virtualization, effectively moving the code that''s already in Xen
into these domains.
> And Xen will end up with a) the Xen core, b) "hardware domain"
guest OS
> patch and c) general guest patches. Now we have a) and c), only... :-)
Kind of, but its wrong to think of driver domains as conventional
guest OSes : nobody logs into them so there''s no need to apply
Linux security patches etc. They can be a linux snapshot that''s
only occasionally updated when the linux device driver model
changes.

For convenience, we''ll probably maintain all the patches in the
same xenolinux tree, i.e. the arch-xeno guest patches, the
privileged domain patches, and the device virtualization
patches. It''ll just be a configuration option to determine what
kind of domain gets built.
 
However, it''s our aim to get arch-xeno and privileged domain
patches into the main-line linux tree at some point, but it
probably wouldn''t be appropriate to have the device
virtualization patches there. We''ll then maintain a snapshot just
for driver domains in the Xen tree.
> Making the core small is very good, but enlarging the rest - the
"guest"
> universe - is not so good...
I don''t think there''s going to be any significant net change
in
the amount of source code that we have to maintain.  The driver
domains will be a bit fatter in terms of memory usage than when
the drivers were in Xen, but we''re only talking about a total of
a few of MB.

Having the device drivers outside of Xen gives us a great deal of
flexibility, making it rather easier to implement things like CoW
sparse virtual disks, layer 4 firewalling, IPv6 etc.

I think the new IO architecture is going to be a significant step
forward in terms of hardware support and flexibility. Trust us ;-)

Cheers,
Ian


-------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel