[libvirt-users] Detecting Co-residency of VMs on KVM

[Shikhar Agarwal]

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


On Thu, Feb 16, 2012 at 5:26 AM, Whit Blauvelt <whit.virt at transpect.com>wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20120216/cd8aa6da/attachment.htm>