[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.