Thank you for the answers. Actually the thing is that I am actually doing a Security project. Me and my professor are trying to determine the physical features of the hardware sitting on a VM. Clearly, if we succeed in doing this, we could raise new security issues about Virtualization. The first step involved detecting co-residency, and we thought we would ask the libvert-users community if they have some good strategies for the same. Thank you <div class="gmail_quote">On Thu, Feb 16, 2012 at 5:26 AM, Whit Blauvelt <<a href="mailto:whit.virt@transpect.com">whit.virt@transpect.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="HOEnZb"><div class="h5">On Wed, Feb 15, 2012 at 03:20:40PM -0700, Eric Blake wrote: > On 02/15/2012 11:08 AM, Shikhar Agarwal wrote: > > I am doing an experiment which involves detecting co-resident VMs (testing > > if 2 VMs are on the same physical machine) on KVM. I have tried using cache > > covert channel, but this test does not work if the VMs are on different > > processors within the same host as the caches are not shared then. If I use > > the tools netperf and iperf to differentiate using network channels, I am > > not getting clear results. This is because the network is really good (10 > > Gbps). I believe there are better and more reliable ways for the same. > > Please suggest some of these. > > The idea is to find some resource (like memory, disk, etc) that is shared > > by the VMs and try to run some benchmarks that thrash this resource. > > Another idea is to take advantage of some optimization that kvm might be > > doing internally. Please help me. > > By default, under the sVirt rules set up by libvirt, VMs should NOT be > sharing resources, and any VM that can reliably detect that it is > co-resident with another VM means you have potentially found a security > hole in qemu or sVirt. In fact, recent libvirt additions such as the > use of cgroups for cpu and I/O throttling should manage even the > possibility for one VM to thrash resources in such a way that steals > time from other VMs. > > As such, I'm afraid you might not get much public response for other > covert channels to look for; admitting to a security hole without also > providing a patch against it is difficult to do in a publicly archived list. </div></div>Couldn't one approximate the co-residency detection by having a script on each of the hosts periodically write files on the guests providing them with whatever information is pertinent? Since this is about the host having access to the guests, it shouldn't violate the security model. The file could contain any arbitrary information available to the host, including the host's name and the specs on other guests it currently hosts. Whether this is wise is a different debate. The point is only that it's trivial for the host to run a script leveraging virsh to identify each running guest, build a file listing them, and place it by one of the many standard file transfer methods on each of the guests. If an admin is doing this as a one-off, even the potential unwisdom of it is mitigated by the obscurity of the implementation - it would not be a standard file in a standard place for an intruder on the guest to reference. Whit </blockquote></div>