From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] Enhance perf to collect KVM guest os statistics from host side Date: Tue, 16 Mar 2010 13:06:42 -0500 Message-ID: <4B9FC8B2.6070404@linux.vnet.ibm.com> References: <20100316112500.GA5337@elte.hu> <4B9F77E7.2060101@redhat.com> <20100316122903.GA8831@elte.hu> <4B9F7C6A.3070207@redhat.com> <20100316130840.GA24808@elte.hu> <4B9F84C0.70706@redhat.com> <20100316133114.GB575@elte.hu> <20100316155221.GA19699@elte.hu> <4B9FC11A.1070507@linux.vnet.ibm.com> <20100316175243.GC23859@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Frank Ch. Eigler" , Avi Kivity , "Zhang, Yanmin" , Peter Zijlstra , Sheng Yang , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Marcelo Tosatti , oerg Roedel , Jes Sorensen , Gleb Natapov , Zachary Amsden , ziteng.huang@intel.com To: Ingo Molnar Return-path: In-Reply-To: <20100316175243.GC23859@elte.hu> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 03/16/2010 12:52 PM, Ingo Molnar wrote: > * Anthony Liguori wrote: > > >> On 03/16/2010 10:52 AM, Ingo Molnar wrote: >> >>> You are quite mistaken: KVM isnt really a 'random unprivileged application' in >>> this context, it is clearly an extension of system/kernel services. >>> >>> ( Which can be seen from the simple fact that what started the discussion was >>> 'how do we get /proc/kallsyms from the guest'. I.e. an extension of the >>> existing host-space /proc/kallsyms was desired. ) >>> >> Random tools (like perf) should not be able to do what you describe. It's a >> security nightmare. >> > A security nightmare exactly how? Mind to go into details as i dont understand > your point. > Assume you're using SELinux to implement mandatory access control. How do you label this file system? Generally speaking, we don't know the difference between /proc/kallsyms vs. /dev/mem if we do generic passthrough. While it might be safe to have a relaxed label of kallsyms (since it's read only), it's clearly not safe to do that for /dev/mem, /etc/shadow, or any file containing sensitive information. Rather, we ought to expose a higher level interface that we have more confidence in with respect to understanding the ramifications of exposing that guest data. >> >> No way. The guest has sensitive data and exposing it widely on the host is >> a bad thing to do. [...] >> > Firstly, you are putting words into my mouth, as i said nothing about > 'exposing it widely'. I suggest exposing it under the privileges of whoever > has access to the guest image. > That doesn't work as nicely with SELinux. It's completely reasonable to have a user that can interact in a read only mode with a VM via libvirt but cannot read the guest's disk images or the guest's memory contents. > Secondly, regarding confidentiality, and this is guest security 101: whoever > can access the image on the host _already_ has access to all the guest data! > > A Linux image can generally be loopback mounted straight away: > > losetup -o 32256 /dev/loop0 ./guest-image.img > mount -o ro /dev/loop0 /mnt-guest > > (Or, if you are an unprivileged user who cannot mount, it can be read via ext2 > tools.) > > There's nothing the guest can do about that. The host is in total control of > guest image data for heaven's sake! > It's not that simple in a MAC environment. Regards, Anthony Liguori > All i'm suggesting is to make what is already possible more convenient. > > Ingo >