lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100319172903.GI13108@8bytes.org>
Date:	Fri, 19 Mar 2010 18:29:03 +0100
From:	oerg Roedel <joro@...tes.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Avi Kivity <avi@...hat.com>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, zhiteng.huang@...el.com,
	Fr??d??ric Weisbecker <fweisbec@...il.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH] Enhance perf to collect KVM guest os statistics from
	host side

On Fri, Mar 19, 2010 at 09:21:22AM +0100, Ingo Molnar wrote:
> Unfortunately, in a previous thread the Qemu maintainer has indicated that he 
> will essentially NAK any attempt to enhance Qemu to provide an easily 
> discoverable, self-contained, transparent guest mount on the host side.
> 
> No technical justification was given for that NAK, despite my repeated 
> requests to particulate the exact security problems that such an approach 
> would cause.
> 
> If that NAK does not stand in that form then i'd like to know about it - it 
> makes no sense for us to try to code up a solution against a standing 
> maintainer NAK ...

I still think it is the best and most generic way to let the guest do
the symbol resolution. This has several advantages:

	1. The guest knows best about its symbol space. So this would be
	   extensible to other guest operating systems.  A brave
	   developer may even implement symbol passing for Windows or
	   the BSDs ;-)

	2. The guest can decide for its own if it want to pass this
	   inforamtion to the host-perf. No security issues at all.

	3. The guest can also pass us the call-chain and we don't need
	   to care about complicated of fetching from the guest
	   ourself.

	4. This way extensible to nested virtualization too.

How we speak to the guest was already discussed in this thread. My
personal opinion is that going through qemu is an unnecessary step and
we can solve that more clever and transparent for perf.

	Joerg

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ