[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100317085351.GF16374@elte.hu>
Date: Wed, 17 Mar 2010 09:53:51 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Anthony Liguori <aliguori@...ux.vnet.ibm.com>
Cc: "Frank Ch. Eigler" <fche@...hat.com>, Avi Kivity <avi@...hat.com>,
"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Sheng Yang <sheng@...ux.intel.com>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Marcelo Tosatti <mtosatti@...hat.com>,
oerg Roedel <joro@...tes.org>,
Jes Sorensen <Jes.Sorensen@...hat.com>,
Gleb Natapov <gleb@...hat.com>,
Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com
Subject: Re: [PATCH] Enhance perf to collect KVM guest os statistics from
host side
* Anthony Liguori <aliguori@...ux.vnet.ibm.com> wrote:
> 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.
What did you think, that it would be world-readable? Why would we do such a
stupid thing? Any mounted content should at minimum match whatever policy
covers the image file. The mounting of contents is not a privilege escallation
and it is already possible today - just not integrated properly and not
practical. (and apparently not implemented for all the wrong 'security'
reasons)
> The guest may encrypt it's disk image. It still ought to be possible to run
> perf against that guest, no?
_In_ the guest you can of course run it just fine. (once paravirt bits are in
place)
That has no connection to 'perf kvm' though, which this patch submission is
about ...
If you want unified profiling of both host and guest then you need access to
both the guest and the host. This is what the 'perf kvm' patch is about.
Please read the patch, i think you might be misunderstanding what it does ...
Regarding encrypted contents - that's really a distraction but the host has
absolute, 100% control over the guest and there's nothing the guest can do
about that - unless you are thinking about the sub-sub-case of Orwellian
DRM-locked-down systems - in which case there's nothing for the host to mount
and the guest can reject any requests for information on itself and impose
additional policy that way. So it's a security non-issue.
Note that DRM is pretty much the worst place to look at when it comes to
usability: DRM lock-down is the anti-thesis of usability. Do you really want
KVM to match the mind-set of the RIAA and MPAA? Why do you pretend that a
developer cannot mount his own disk image? Pretty please, help Linux instead,
where development is driven by usability and accessibility ...
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists