Re: Qemu plugin vs. valgrind

[Marc Hacin]

Le 31/03/2020 à 16:38, Alex Bennée a écrit :
> Marc Hacin <address@hidden> writes:
>
> > Le 31/03/2020 à 02:28, Benjamin a écrit :
> > > Perhaps you're looking for something like this?
> > > https://wiki.qemu.org/Internships/ProjectIdeas/CacheModelling
> >
> > I don't think so.
> > I made a few tries of a plugin, made from copy/pasting existing ones
> > in QEMU's github.
> >
> > I would like to monitor how data, in guest code, obtained by read()
> > [user] or I/O registers [system], scatters in guest memory by
> > side-effects.
> > One side-effect I'm thinking of is when a guest core register holding
> > such data because of calculations on it, is saved on the stack because
> > of a call. And then in another call an uninitialized local variable
> > unlikely gets its value from this register saving.
>
> So at the moment you can't see the register contents. But I'm not quite
> following this "side effect" you are talking about. Any instruction that
> either loads or stores something in memory can be instrumented without
> knowledge of in which register the address was held in.
>
> If you really need to track that you could disassemble each instruction
> at translation time to work out which registers are being used.

Yes, I concluded to that.
It is a part of the "in_asm->op" job. That is why I thought having 
access to it inside a plugin would avoid that rework.


> > Something like https://github.com/wmkhoo/taintgrind
> >
> > After the tries I made with my QEMU plugin, and use of "-d in_asm,op
> > -dfilter x+n", I think that these plugins cannot serve my need (but
> > global stats).
> > I should have to dig into in_asm->op conversions, probably a too
> > complex task. To add tracking code of a "tainted" attribute to every
> > byte of guest memory and registers.
>
> That is an internal implementation detail the TCG plugins will never expose.
>
> >  From -d, I guess that guest registers are emulated by standard host
> > variables ?
>
> Again an internal implementation detail the plugins don't expose.
>
> > With my understanding of the TCG based emulation, the supercalar /
> > pipelines properties of the guest processor may be not emulated, but
> > conforms to the host. Am I right ?
>
> Yes - QEMU is not attempting to emulate any micro architectural details.
> It only cares about getting the semantics of the emulated instruction
> correct.
>
> > On my tests, mono-core, it seems that the load/store callback is
> > called just after the call of the instruction-before callback which is
> > the source of the load/store. I didn't see any intermix between memory
> > and instruction callback, as it is the case on the real guest core.
>
> Why would there be? All memory operations will be the result of an
> instruction being executed.

On the processor core I use, executing :
        ldwz ra,(rb)            /* insA */
        ldwz rc,(rd)            /* insB */
doesn't tell if ra is filled before rc. For exemple if rb points to slow 
PCI space, ra could be filled thousands of processor cycles after the 
insA  load request. Enough to run hundred's of instructions like insB as 
long as ra is not referenced.
In QEMU, it seems the callback are called pretty synchronously with 
guest instruction flow (because of the many host instructions put around 
I guess, and depending of host architecture).
So perhaps one can expect that the mem callback of a load instruction is 
always called before any other cb (in my taint analysis, it doesn't 
matter).


> > It would be great for users (like me) that QEMU provide another plugin
> > stage, at the "in_asm->op" process, as there are useful possible
> > analysers features here. Same as the popular valgrind's ones (and
> > valgrind is not cross-arch/OS as QEMU is).
> > A bigger dream would be plugins compatibility to inherit valgrind ones
> > (but IRs are not the same I think).
>
> We very deliberately don't expose internal TCG details. I suggest you
> re-read docs/devel/tcg-plugins.rst for the rationale about this.

Yes, I read that already.

> > > QEMU also supports a GDB stub, which might help with your last question.
> > > https://wiki.qemu.org/Features/gdbstub
> >
> > Eventually, I have tested my plugin with a user mode guest statically
> > and absolutely linked ELF (with no relocations).
> > Then I passed trigger information to my plugin via the argv feature.
> >
> >
> > Thanks for your answers.

--
Thierry Bernier