Re: [Valgrind-users] valgrind as a dynamic monitor

[Michael E. L. <me...@co...>]

On Friday 29 August 2003 02:13 am, Tom Hughes wrote:
> In message <200...@co...>
>
>           "Michael E. Locasto" <me...@co...> wrote:
> > I'm wondering if there is any way that valgrind can be dynamically tu=
rned
> > on and off during execution; that is, instead of valgrind translating=
 and
> > instrumenting the executable right away, can it allow the program to
> > execute on the real CPU until a macro is called from the program, at
> > which point it could start the translation and instrumentation until =
some
> > later point (another macro that VG will recognize) and return control=
 to
> > the real CPU and the uninstrumented code.
>
> If you did that, how would valgrind know what memory was initialised
> whe you turned it on? Any changes made while it would off would not be
> known about and it wouldn't be able to report errors properly when you
> turned it back on.

In this context, it's ok. I'm looking to run the program inside Valgrind,=
 but=20
_not_ incur the cost of translation and emulation during much of the runt=
ime.=20
The purpose would be to provide a sandbox for production servers that can=
=20
protect against certain buffer overflow attacks.

The "turn on" point would be where we care about starting to keep track o=
f=20
values. A snapshot of the current "real" CPU state would be stored in mem=
ory=20
and the instrumented execution (in valgrind) would begin. At the "turn of=
f"=20
point, if all memory accesses were clean (no corruption of heap or stack,=
=20
etc.) we would merrily return to the real CPU. If not, we would roll memo=
ry=20
back to the last known good state snapshot and return to the real CPU.

Kind of like how Valgrind does function calls, but in reverse.

Cheers,
Michael