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.v...@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 >
_______________________________________________ libvirt-users mailing list libvirt-users@redhat.com https://www.redhat.com/mailman/listinfo/libvirt-users
