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

[Peter Maydell]

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.

thanks
-- PMM