Re: [Valgrind-users] Re: memory check on the stack

[Steve G <lin...@ya...>]

>The problem is that valgrind doesn't have a concept of 
>write protected memory. 

I don't think the solution is that complicated. Libsafe does this
correctly. It has never killed a program that I know of doing
something weird with alloca. Libsafe also is a LD_PRELOAD
interceptor, which means it works with uninstrumented code just
like valgrind.

Whenever there is a mov in a loop (memcpy & strcpy) the current
stackframe can be watched to see if it gets overwritten. read,
recv, recvfrom, etc, can also be watched to see if their results
overwrite a return address.

If alloca does move the return address, I would think that a call
to alloca can be identified and the "return address to watch"
changed to the new address.

Another approach that I might experiment with is to "valgrindify"
libsafe with its macros (libsafe has a tendency to outright kill
a program), modify the startup bash script to LD_PRELOAD libsafe
too, and let valgrind collect the messages.

I really believe its possible to detect these problems. The
question is just how to do it.

-Steve Grubb

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus