The following series implements dynamic binary instrumentation upon QEMU. It is based on the following prior sources: - KVM Forum 2017 talk "Instrumenting, Introspection, and Debugging with QEMU" https://www.linux-kvm.org/images/3/3d/Introspect.pdf - Discussion on Lluis Vilanova instrumentation patch series https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg03357.html
There are many implementations of the instrumentation for QEMU. We have our own attempt on github: https://github.com/ispras/qemu/tree/plugins But this series differ from that approach and it is intended to provide a stable interface for adding and extending the QEMU binary analysis functions. We propose adding new instrumentation API for QEMU which will include the following parts: - some translator modifications to enable instrumenting the instructions (and memory operations in the next version of the patches) - dynamic binary instrumentation part (a sample which is currently submitted in this RFC series) - subsystem for dynamically loaded plugins that interact with this API (not ready yet) The aim of the instrumentation is implementing different runtime tracers that can track the executed instructions, memory and hardware operations. The implementation should not incur too much overhead to make memory tracing as efficient as it is possible for this heavy task. The plugins should not have too many dependencies from the QEMU core. They should be built as a separate projects using just a couple of the headers. For the current patches the plugins should provide the following callbacks: - "needs" callback to check whether the specific instruction should be instrumented by this plugin - "run" callback which called before executing the instuction Our instrumentation subsystem exploits TCG helper mechanism to embed callbacks into the translation blocks. These callbacks may be inserted before the specific instructions. The aim of submission of this series at that early stage is to get the feedback which will guide the development process. We are faced the following questions: - Is the double parsing of the instruction opcode ok? (syscall sample) Or we should construct a method for passing analysis-specific parameters from the instrumenting stage to the execution one? - Does every plugins should have its own callback embedded into the TB (which will cause TB extra growth in case of multiple plugins), or the instrumentation layer's callback should invoke the plugins that wanted to instrument that specific instruction? - How the plugins should function? Will they work as a binary dynamic libraries or a script on some interpreted language? --- Pavel Dovgalyuk (2): tcg: add headers for non-target helpers tcg: add instrumenting module accel/tcg/Makefile.objs | 1 accel/tcg/instrument/Makefile.objs | 1 accel/tcg/instrument/helper.h | 1 accel/tcg/instrument/instrument.c | 82 ++++++++++++++++++++++++++++++++++++ accel/tcg/instrument/instrument.h | 11 +++++ accel/tcg/translate-all.c | 2 + accel/tcg/translator.c | 5 ++ include/exec/helper-register.h | 53 +++++++++++++++++++++++ tcg/tcg.c | 12 +++++ tcg/tcg.h | 3 + 10 files changed, 171 insertions(+) create mode 100644 accel/tcg/instrument/Makefile.objs create mode 100644 accel/tcg/instrument/helper.h create mode 100644 accel/tcg/instrument/instrument.c create mode 100644 accel/tcg/instrument/instrument.h create mode 100644 include/exec/helper-register.h -- Pavel Dovgalyuk
