[Qemu-devel] Re: valgrind functionality in qemu?

[Ben Pfaff <blp@cs.stanford.edu>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Unfortunately, you didn't publish the source code for TaintBochs.

It's not very pretty.  We're working on a nicer version that we
might release later.

> So how did you tackle following problems:
>
> - when deciding what to taint, you want to be as specific as possible. How
> did you tell bochs what was tainted, and what not?

This isn't really relevant for the purpose of doing valgrind-like
functionality, for what it's worth.  However, we used various
methods.  For example, for tainting passwords input from the
keyboard we added a toggle switch to the Bochs interface that
determined whether keypressed were considered tainted, and for
tainting network input we did a simple string search in network
packets (which is not very smart but worked okay for the simple
case we wanted to try).

> - when you tested inside bochs, you didn't have control over loading of
> programs. How did bochs know where the code came from?

We used Mission Critical's "crash" utility as a kernel debugger.
We added a module to it that allowed us to generate a core dump
of any process in the guest.  When you combine a core dump with
the program binary and the program source, gdb and addr2line can
tell you everything you want to know.

> - even more importantly, when you analyzed where tainting data was
> propagated or freed, how did you find out which *source code* was
> responsible for that?

gdb and addr2line as above.

I think all this is in the paper actually.  We included a fair
number of details of our implementation there.

> I would do tha "just write some code" part, but I still look for
> elegant solutions to those problems.

-- 
"The road to hell is paved with convenient shortcuts."
--Peter da Silva