|
From: Michael E. L. <me...@co...> - 2003-08-29 02:45:55
|
Hey all,
I'm wondering if there is any way that valgrind can be dynamically turned=
on=20
and off during execution; that is, instead of valgrind translating and=20
instrumenting the executable right away, can it allow the program to exec=
ute=20
on the real CPU until a macro is called from the program, at which point =
it=20
could start the translation and instrumentation until some later point=20
(another macro that VG will recognize) and return control to the real CPU=
and=20
the uninstrumented code.=20
I'm looking to turn valgrind into a kind of virtual machine monitor, wher=
e=20
only certain functions need to be instrumented. If said functions behave=20
badly, then control can return safely to the real CPU and the side effect=
s of=20
the function undone.
I played around with the idea of writing a skin to do this (much like the=
null=20
skin, however, I don't want to incur the cost of translating if the code=20
isn't going to be instrumented), but despite the good documentation on th=
e=20
website, I'm not sure if a skin is the proper solution; this seems more l=
ike=20
a fundamental change to the valgrind startup code. Is this possible?
Comments and suggestions are most welcome.
Cheers,
Michael
---------------------------------------------------------
For example,
// where the TURN_ON|OFF macros are defined
#include "valgrind.h"
int foo_process( char* data ){
// do some work that needs to be watched
}
int main(){
//...run, do some processing
VG_TURN_ON( skin_name ); /* turn valgrind & instrumentation on */
=09 foo_process( input_data ); /* invoke the code your interested in =
*/
VG_TURN_OFF( skin_name ); /* turn valgrind & instrumentation off */
//... keep on moving on
}
|
|
From: Tom H. <th...@cy...> - 2003-08-29 06:14:07
|
In message <200...@co...>
"Michael E. Locasto" <me...@co...> wrote:
> I'm wondering if there is any way that valgrind can be dynamically turned 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.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-29 07:31:23
|
On Fri, 29 Aug 2003, Tom Hughes wrote: > > I'm wondering if there is any way that valgrind can be dynamically turned 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. Yes, it doesn't seem possible with the Memcheck skin, because Memcheck's metadata (the A and V bits) depend on the entire execution history. It's the same with Addrcheck, Helgrind and Cachegrind. However, Michael also said: > I'm looking to turn valgrind into a kind of virtual machine monitor, > where only certain functions need to be instrumented. If said functions > behave badly, then control can return safely to the real CPU and the > side effects of the function undone. In which case the previous execution history might not matter. Unfortunately, I don't see how this could be made to work... switching from the real world to Valgrind-land seems exceedingly difficult. One example I think of immediately is signal handling -- if the program installed signal handlers before switching, the kernel would call these handlers without Valgrind having a chance to intercept and then the program would be half in Valgrind-land and half not, which would very quickly lead to disaster, I imagine. I'm sure there are other grand difficulties involved as well. If you only want to instrument certain functions, you could write a skin that does that. Then for most of the program you'd have the 5x or so slowdown you get with no instrumentation, and the instrumented functions would run more slowly. Accurately instrumenting only certain functions may require debug information to be present in your programs, however. Depends exactly what you want to do. Can you give more detail about what you want to do with this virtual machine monitor? That might help in identifying ways of achieving your goals. N |
|
From: Michael E. L. <me...@co...> - 2003-08-29 19:25:10
|
On Friday 29 August 2003 03:30 am, Nicholas Nethercote wrote: > On Fri, 29 Aug 2003, Tom Hughes wrote: > > <snip/> > > If you only want to instrument certain functions, you could write a ski= n > that does that. Then for most of the program you'd have the 5x or so > slowdown you get with no instrumentation, and the instrumented function= s > would run more slowly. Accurately instrumenting only certain functions > may require debug information to be present in your programs, however. > Depends exactly what you want to do. Tom and Nick, thanks for your replies. Points well taken. This was my initial approach, and I began to write a skin to do just this= =2E=20 > Can you give more detail about what you want to do with this virtual > machine monitor? That might help in identifying ways of achieving your > goals. The motivating example here is a fairly ambitious project to automaticall= y=20 patch certain known classes of software vulnerabilities like stack or=20 heap-based overflows.=20 The primary use of the virtual machine monitor would be to test a suspect= ed=20 infection vector (the byte stream that will cause the overflow and the=20 subsequent appearance of a worm) on an appropriately instrumented=20 version of the application (Apache, etc.) If the infection vector does ca= use=20 an overflow, then we can use Valgrind to identify the specific buffer and= =20 detect if execution has shifted to the stack, heap, or some other locatio= n=20 (like an unused library function). This creates a transaction analogy, where "unsuccessful" transactions (th= ose=20 in which the potential infection vector causes infection/abnormal operati= on)=20 are rolled back (effectively ignored) and execution continues. Cheers, Michael |
|
From: Steve G <lin...@ya...> - 2003-08-29 19:51:29
|
>The motivating example here is a fairly ambitious >project to automatically patch certain known classes >of software vulnerabilities like stack or heap-based >overflows. Have you looked at libsafe? It might be an easier approach to do this kind of thing. As a matter of fact, I have hacked it to add instrumentation for several more overflows than the authors did. You can get my imprroved version here: www.web-insights.net/libsafe. You can diff it against the official version to see how easy it is to add instrumentation. As for doing a transaction based system, it sounds like you are going to be doing a setjmp & longjmp when it doesn't work out. This is similar in concept to libchkpt which is a check pointing library. The only difference is that rather than moving the process to another machine, you will want to do something else. You may be able to adapt libsafe+libchkpt to achieve a transaction based system. Sounds interesting. -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Michael E. L. <me...@co...> - 2003-08-29 22:33:34
|
On Friday 29 August 2003 03:51 pm, Steve G wrote: > > As for doing a transaction based system, it sounds like you > are going to be doing a setjmp & longjmp when it doesn't > work out. This is similar in concept to libchkpt which is a > check pointing library. The only difference is that rather > than moving the process to another machine, you will want > to do something else. > > You may be able to adapt libsafe+libchkpt to achieve a > transaction based system. Sounds interesting. Great suggestion, thanks. I appreciate the pointers. I'll check out your additions to libsafe and look into combining a libckp= t=20 approach. As I understand it, our main problem with using libsafe is twof= old:=20 its termination of the process when an overflow is discovered, and libsaf= e=20 only covers certain C library functions. We'd want to mark sections of co= de=20 that should be run intstrumented no matter what functions are inside the=20 marked section. In addition, we're really looking for fine-grained tracking of memory (mo= re=20 than the bounds checking done by libsafe/libverify, Stackguard, Propolice= ,=20 etc.) -- and Valgrind seems to provide that capability very well. Cheers, Michael |
|
From: Steve G <lin...@ya...> - 2003-08-30 01:46:02
|
>As I understand it, our main problem with using >libsafe is twofold: its termination of the process >when an overflow is discovered, Right. This is where the libckpt stuff comes in. You would want to change that behavior and use one of the proces restoration calls when the overflow was detected. Just to make sure we are talking about the same library, you can find it here: http://www.cs.utk.edu/~plank/plank/www/libckpt.html >and libsafe only covers certain C library functions. Right. This is a limitation. Valgrind is much more flexible in this regard. However, if you really grok what libsafe is doing, and you have a modern compiler that supports typeof, you might be able to abstract what they are doing and create a generic instrumentation routine. >In addition, we're really looking for fine-grained >tracking of memory (more than the bounds checking ) Right. Libsafe only does one thing...and it does it pretty well. Valgrind is much more flexible for general memory problems. But as others pointed out, it may be hard to turn on and off at will. That's why I was focusing on something a little easier, but not as powerful as valgrind. In any event, it sounds like an interesting project. Best Regards, Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |
|
From: Michael E. L. <lo...@cs...> - 2003-09-03 19:35:11
|
Steve, Good point. Thanks very much for your help. I guess I'll try both approac= hes=20 and see which ones causes less pain. > Right. Libsafe only does one thing...and it does it pretty > well. Valgrind is much more flexible for general memory > problems. But as others pointed out, it may be hard to turn > on and off at will. That's why I was focusing on something > a little easier, but not as powerful as valgrind. > > In any event, it sounds like an interesting project. I hope so :) Cheers, Michael |
|
From: Nicholas N. <nj...@ca...> - 2003-08-30 14:53:26
|
On Fri, 29 Aug 2003, Michael E. Locasto wrote:
> The motivating example here is a fairly ambitious project to automatically
> patch certain known classes of software vulnerabilities like stack or
> heap-based overflows.
You should read this paper:
@InProceedings{Kir:shepherding2002,
author = {Vladimir Kiriansky and Derek Bruening and Saman Amarasinghe},
title = {Secure Execution Via Program Shepherding},
booktitle = {Proceedings of the 11th USENIX Security Symposium},
pages = {191--206},
address = {San Francisco, California, USA},
month = aug,
year = 2002,
summary = {Nice paper about preventing a broad range of security
attacks such as format-string and stack overwrite attacks.
Doesn't try to detect the attack itself, but rather its
effect; watches for control transfers to suspicious (eg.
injected) code. Does this by (a) only running code that
comes from trusted origins (eg. binary image, libraries),
(b) restricting control flow transfers and (c) using
"uncircumventable" sandboxing. Built with Dynamo/RIO, a
fast Valgrind-like program supervision meta-tool. The
sandboxing is used to avoid attacks against RIO itself.
Performance is excellent, on average about 1.1--1.2 times
slower than unprotected, on Linux and Windows.},
}
I'm not sure whether the described system is available for general use,
but it sounds a lot like what you're suggesting.
N
|
|
From: Michael E. L. <me...@co...> - 2003-08-29 19:41:31
|
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 |
|
From: Nigel H. <nj...@ba...> - 2003-09-06 11:03:03
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does valgrind support Red Hat 9? I've tried it on a couple of machines, but= the "make" stage always fails. make all-recursive make[1]: Entering directory `/home/njh/src/valgrind-20030725' Making all in coregrind make[2]: Entering directory `/home/njh/src/valgrind-20030725/coregrind' Making all in demangle make[3]: Entering directory `/home/njh/src/valgrind-20030725/coregrind/dema= ngle' if cc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../coregrind -I../../include = =2DWinline -Wall -Wshadow -O -fomit-frame-pointer -g -mpreferred-stack-boun= dary=3D2 -Wno-unused -Wno-shadow -MT cp-demangle.o -MD -MP -MF ".deps/cp-d= emangle.Tpo" \ -c -o cp-demangle.o `test -f 'cp-demangle.c' || echo './'`cp-demangle.c; \ then mv ".deps/cp-demangle.Tpo" ".deps/cp-demangle.Po"; \ else rm -f ".deps/cp-demangle.Tpo"; exit 1; \ fi make: expand.c:489: allocated_variable_append: Assertion `current_variable_= set_list->next !=3D 0' failed. make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/njh/src/valgrind-20030725/coregrind' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/njh/src/valgrind-20030725' make: *** [all] Error 2 =2D --=20 Nigel Horne. Arranger, Composer, Typesetter. NJH Music, Barnsley, UK. ICQ#20252325 nj...@de... http://www.bandsman.co.uk =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/Wb7ehTUd3VwpF6IRApqsAJ9SuJ8pyxNlBlbmqevC9BgF2P5+6wCdEPOz OXbBULD+wvn9QsHVRZHmr6Q=3D =3Dqdbp =2D----END PGP SIGNATURE----- |
|
From: Nicholas N. <nj...@ca...> - 2003-09-06 11:23:52
|
On Sat, 6 Sep 2003, Nigel Horne wrote:
> Does valgrind support Red Hat 9? I've tried it on a couple of machines,
> but the "make" stage always fails.
From FAQ.txt:
Q16. When I trying building Valgrind, 'make' dies partway with an
assertion failure, something like this: make: expand.c:489:
allocated_variable_append: Assertion
`current_variable_set_list->next != 0' failed.
A16. It's probably a bug in 'make'. Some, but not all, instances of
version 3.79.1 have this bug, see
www.mail-archive.com/bug...@gn.../msg01658.html. Try upgrading to a
more recent version of 'make'.
N
|
|
From: Nigel H. <nj...@ba...> - 2003-09-06 11:29:19
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 06 Sep 2003 12:23 pm, you wrote: > Try upgrading > to a more recent version of 'make'. I have the latest RPM already. > > > N =2D -Nigel =2D --=20 Nigel Horne. Arranger, Composer, Typesetter. NJH Music, Barnsley, UK. ICQ#20252325 nj...@de... http://www.bandsman.co.uk =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/WcUIhTUd3VwpF6IRAgMSAJ9V2yPzju3GbbOS84MYpsA1GNSfiQCfQuaC 9WkZaEl0CRblAIehg/S+YQ4=3D =3Dojb2 =2D----END PGP SIGNATURE----- |
|
From: Dirk M. <dm...@gm...> - 2003-09-06 12:04:07
|
On Saturday 06 September 2003 13:29, Nigel Horne wrote: > > Try upgrading > > to a more recent version of 'make'. > I have the latest RPM already. then the rpm is still broken. it works with any reasonably recent make. |
|
From: Tom H. <th...@cy...> - 2003-09-06 12:14:30
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Saturday 06 September 2003 13:29, Nigel Horne wrote:
>
> > > Try upgrading
> > > to a more recent version of 'make'.
> > I have the latest RPM already.
>
> then the rpm is still broken. it works with any reasonably recent make.
I have no problem building on RH9 and I am using the standard
RedHat RPM of make. Obviously some people do seem to have trouble
with 3.79 but that is only one version behind the latest, so it's
not like the 3.79 isn't reasonably recent.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|