[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Qemu plugin vs. valgrind
From: |
Marc Hacin |
Subject: |
Re: Qemu plugin vs. valgrind |
Date: |
Tue, 31 Mar 2020 15:13:19 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 |
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.
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.
From -d, I guess that guest registers are emulated by standard host
variables ?
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 ?
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.
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).
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