libvirt users - Feb 2012 - Detecting Co-residency of VMs on KVM

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.

Thank you
Shikhar Agarwal
Undergraduate Senior
IIT-Delhi
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20120215/baf5f99d/attachment.htm>

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.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20120215/f4874ec3/attachment.sig>