|
From: Henrik N. <hn...@ma...> - 2004-01-22 13:21:33
|
I am currently fighting with a bad case of "return into 0" due to a smashed stack like what was discussed by S=E9bastien de Menten some days = ago in the memory check on the stack thread. After some analysis of the problem I have some ideas on what valgrind can do to help nailing these down. As valgrind is running an emulation it should be possible to detect function entry/exit and then change the protection of the return address, frame pointer etc on the stack to read-only until return from the function (where the same gets fully protected as it is now outside the active stack area). This way it should be possible to detect these errors better than StackGuard or other simila= r approaches to the problem without having to instrument the binary code. Rebuilding applications and all relevant libraries with full instrumentation like mudflap is also an option I guess, but not by far as= =20 easy for the developer. Regards Henrik |
|
From: Tom H. <th...@cy...> - 2004-01-22 13:29:48
|
In message <Pin...@fi...>
Henrik Nordstrom <hn...@ma...> wrote:
> After some analysis of the problem I have some ideas on what valgrind can
> do to help nailing these down. As valgrind is running an emulation it
> should be possible to detect function entry/exit and then change the
> protection of the return address, frame pointer etc on the stack to
> read-only until return from the function (where the same gets fully
> protected as it is now outside the active stack area). This way it should
> be possible to detect these errors better than StackGuard or other similar
> approaches to the problem without having to instrument the binary code.
If you read that thread you'll see that valgrind doesn't have a
concept of read-only, so it isn't that easy. It's also surprisingly
hard to spot function entry/exit in valgrind because of various
non-local control flow mechanisms that exist.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
> ... valgrind doesn't have a concept of read-only, ... Could the combination (0==AccessBit, <pattern>==ValidBits) be used for this purpose? This would require that de-allocations (free(), stack trim, etc.) zero the ValidBits as well as the AccessBit; but memset() is not too expensive, especially if it is optional. > It's also surprisingly > hard to spot function entry/exit in valgrind because of various > non-local control flow mechanisms that exist. What else besides setjmp()/longjmp(), tail recursion elimination as implemented by gcc 3.3, and complications due to alloca()? Each of these is some work, but mostly tedious instead of difficult. -- |