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

Re: Fw: [Xen-devel] Xen on /. again

> It almost certainly can't be implemented at a later date. Even attempting
> to do so (without really succeeding) would require significant incompatible
> changes to the hypervisor interface.

What changes are required depend on what channels you're trying to eliminate.  
You could limit the aforementioned covert channels in the network interface, 
block device head scheduling and also CPU scheduling without changing the 
hypervisor interface at all.

Whether this is worth the effort is another matter, however, as you rightly 
point out ;-)

> Attackers only need a very small 
> bandwidth to transmit many of the things that are most useful from their
> point of view (cryptographic keys, passwords, compressed answers from a
> program that can look at any amount of data), so claims about limiting the
> bandwidth really just give a false sense of security.

Yes.  You just have to hope that organisational security measures compensate 
for the covert channels that remain.

Cheers,
Mark


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel