[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Support for using TCG frontend as a library

From: Alessandro Di Federico
Subject: [Qemu-devel] Support for using TCG frontend as a library
Date: Sun, 27 Nov 2016 20:32:44 +0100

Hi all,
  QEMU is a great emulator, but in recent years it has also been used
for instrumentation purposes [QIRA,AFL] or as a lifter for static
analysis purposes [rev.ng,angr,libqemu,S²E]. I'd like to hear your
take on the second use case, and the possibility of offering upstream
support for it.

The general idea is to introduce a new build configuration which
produces a library for each supported input ISA exposing the TCG
frontend in a unified way. We could call it libtcg-$ARCH.so. In
practice, given a buffer containing code for a certain architecture,
the user program loads the appropriate version of this library and asks
it to produce the corresponding TCG instructions.

I've been investigating the needs of the various projects that might be
interested in using it and they sum up to the following:

* Be able to load in the same process multiple libtcg-$ARCH.so for
  different architectures.
* Obtain the TCG instructions from code in a memory buffer.
* Dump the assembly code of the code in a memory buffer.
* Dump the TCG instructions in textual form.

For what concerns helpers, it would be nice to have some metadata about
them, for instance the parts of the CPU state they can change. It would
also be nice to have a build configuration which produces a library
containing all the helpers ready to be used, or, even better, a library
as LLVM bitcode, which can then be further processed/analyzed.

Here you can find some relevant parts of my draft implementation part
of rev.ng:

* The interface exposed to users:
* Implementation of the interface functions:
* For the changes introduced elsewhere look for CONFIG_LIBTINYCODE:

It's rough but it works (see [rev.ng]). I'm interested to hear your
opinion and willingness to take patches. Being able to unify the
various efforts in this direction would be good, having upstream
support would be amazing.

Alessandro Di Federico
PhD student at Politecnico di Milano

[QIRA] http://qira.me/
[AFL] http://lcamtuf.coredump.cx/afl/ (for the black-box mode)
[rev.ng] https://rev.ng/
[angr] http://angr.io/ (currently using VEX IR, QEMU support planned)
[libqemu] https://github.com/zaddach/libqemu
[S²E] http://s2e.epfl.ch/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]