Re: [libvirt-users] Detecting Co-residency of VMs on KVM
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.
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