On Thu, Jul 27, 2017 at 11:40:17AM +0100, Peter Maydell wrote: > On 27 July 2017 at 11:32, Stefan Hajnoczi <stefa...@redhat.com> 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
