Re: [PATCH] Enhance perf to collect KVM guest os statistics from host side

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/16/2010 01:28 PM, Ingo Molnar wrote:
* Anthony Liguori<aliguori@xxxxxxxxxxxxxxxxxx>  wrote:

On 03/16/2010 12:52 PM, Ingo Molnar wrote:
* Anthony Liguori<aliguori@xxxxxxxxxxxxxxxxxx>   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.
What's your _point_? Please outline a threat model, a vector of attack,
_anything_ that substantiates your "it's a security nightmare" claim.

You suggested "to have a (read only) mount of all guest filesystems".

As I described earlier, not all of the information within the guest filesystem has the same level of sensitivity. If you exposed a generic interface like this, it makes it very difficult to delegate privileges.

Delegating privileges is important because from in a higher security environment, you may want to prevent a management tool from accessing the VM's disk directly, but still allow it to do basic operations (in particular, to view performance statistics).

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.
Exactly, we want something that has a flexible namespace and works well with
Linux tools in general. Preferably that namespace should be human readable,
and it should be hierarchic, and it should have a well-known permission model.

This concept exists in Linux and is generally called a 'filesystem'.

If you want to use a synthetic filesystem as the management interface for qemu, that's one thing. But you suggested exposing the guest filesystem in its entirely and that's what I disagreed with.

If a user cannot read the image file then the user has no access to its
contents via other namespaces either. That is, of course, a basic security
aspect.

( That is perfectly true with a non-SELinux Unix permission model as well, and
   is true in the SELinux case as well. )

I don't think that's reasonable at all. The guest may encrypt it's disk image. It still ought to be possible to run perf against that guest, no?

Erm. Please explain to me, what exactly is 'not that simple' in a MAC
environment?

Also, i'd like to note that the 'restrictive SELinux setups' usecases are
pretty secondary.

To demonstrate that, i'd like every KVM developer on this list who reads this
mail and who has their home development system where they produce their
patches set up in a restrictive MAC environment, in that you cannot even read
the images you are using, to chime in with a "I'm doing that" reply.

My home system doesn't run SELinux but I work daily with systems that are using SELinux.

I want to be able to run tools like perf on these systems because ultimately, I need to debug these systems on a daily basis.

But that's missing the point. We want to have an interface that works for both cases so that we're not maintaining two separate interfaces.

We've rat holed a bit though.  You want:

1) to run perf kvm list and be able to enumerate KVM guests

2) for this to Just Work with qemu guests launched from the command line

You could achieve (1) by tying perf to libvirt but that won't work for (2). There are a few practical problems with (2).

qemu does not require the user to associate any uniquely identifying information with a VM. We've also optimized the command line use case so that if all you want to do is run a disk image, you just execute "qemu foo.img". To satisfy your use case, we would either have to force a use to always specify unique information, which would be less convenient for our users or we would have to let the name be an optional parameter.

As it turns out, we already support "qemu -name Fedora foo.img". What we don't do today, but I've been suggesting we should, is automatically create a QMP management socket in a well known location based on the -name parameter when it's specified. That would let a tool like perf Just Work provided that a user specified -name.

No one uses -name today though and I'm sure you don't either.

The only way to really address this is to change the interaction. Instead of running perf externally to qemu, we should support a perf command in the qemu monitor that can then tie directly to the perf tooling. That gives us the best possible user experience.

We can't do that though unless perf is a library or is in some way more programmatic.

Regards,

Anthony Liguori

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux