Re: [Qemu-devel] [PATCH 00/13] instrument: Add basic event instrumentation

[Stefan Hajnoczi]

On Thu, Jul 27, 2017 at 11:40:17AM +0100, Peter Maydell wrote:
> On 27 July 2017 at 11:32, Stefan Hajnoczi <address@hidden> wrote:
> > On Wed, Jul 26, 2017 at 03:44:39PM +0300, Lluís Vilanova wrote:
> >> And why exactly is this a threat? Because it can be used to "extend" QEMU
> >> without touching its sources? Is this a realistic threat? (it's a rather 
> >> brittle
> >> way to do it, so I'm not sure it's practical)
> >
> > Unfortunately it is a problem.  I recently came across a product that
> > was using LD_PRELOAD= to "integrate" with QEMU.  People really abuse
> > these interfaces instead of integrating their features cleanly into
> > QEMU.
> 
> ...if people who want to do this kind of thing already can and
> do use LD_PRELOAD for it, I don't think we should worry too much
> about trying to make the instrumentation plugin API bulletproof
> against similar abuse.
> 
> > I see the use cases that Peter has been describing and am sure we can
> > come up with good solutions.  What I care about is that it doesn't allow
> > loading a .so that connects to arbitrary trace events.
> 
> That said, I agree that we don't really need an arbitrary-trace-event
> setup here, and we should probably design our API so that it isn't
> handing the trace plugin hooks pointers into QEMU's internals.
> We want an API that makes it easy for people to do things based on
> changes of the guest binary's state (registers, insns, etc etc)
> and which makes it hard for them to accidentally trip themselves up
> (eg by prodding around in QEMU internal data structures).
> This will have the secondary benefit that it's unlikely that future
> changes to QEMU will break plugin code.
> 
> >> As a side note, I find instrumentation to be most useful for guest code 
> >> events,
> >> which mostly contain non-pointer values (except for the CPUState*).
> 
> For instance we definitely should not be passing a CPUState* to
> any plugin function.

The gdbstub protocol has relevant features for accessing guest memory,
registers, etc.  Perhaps a set of QEMU-specific events can be added
(e.g. tb generated) so it's possible to instrument and control the
guest from an instrumentation program (written in any language).

Perhaps there is a fundamental reason why this isn't possible due to the
protocol design, because using gdbstub halts all vcpus, etc.  I don't
know.

Do you think this is an interesting direction?  It definitely seems like
a powerful approach though performance would be less than running native
code inside the QEMU process.

Stefan

signature.asc
Description: PGP signature