Runtime security/memory checks for gcc/gdb

Runtime security/memory checks for gcc/gdb

Elazar Leibovich elazarl at gmail.com
Tue Jan 12 07:48:13 IST 2010


I tried using valgrind in a different project. The main problems I've had
with valgrind are speed (which is not a problem here) and false positives.
Getting gdb to report that during runtime has its advantages.
Anyhow, I was hoping to hear about products/valgrind add-ons etc I do not
know.

The main practical problem with it, is convincing management that getting a
linux box or VM and build the code on it is worth our while...

On Tue, Jan 12, 2010 at 12:27 AM, guy keren <choo at actcom.co.il> wrote:

>
>
> valgrind will tell you whenever you are using an un-ninitialized variable.
> it'll do so using runtime analysis.
>
> have you tried using valgrind at all?
>
> --guy
>
> Elazar Leibovich wrote:
>
>> Just a remark, as some people asked me about it privately.
>> I'm not interested in static analysis (which gcc gives for uninitialized
>> variables). But with runtime analysis of where the uninitialized variable
>> have been actually used when the code was run. This is useful in many
>> situations (for instance, when having 3000 (literally) static warnings, some
>> of similar spirit, and no time to check them all)
>> I didn't find anything parallel to that for gcc.
>>
>> On Mon, Jan 11, 2010 at 11:54 PM, Elazar Leibovich <elazarl at gmail.com<mailto:
>> elazarl at gmail.com>> wrote:
>>
>>    We have a big legacy embedded code we need to maintain. Often, we
>>    wish to run some functions of the code on the PC with injected
>>    input, to test them or to test changes we've done to them without
>>    loading the code to the device it should run on.
>>    The code is written with C.
>>    Obviously, this is not an easy task, it is more difficult because,
>>    the code is bug ridden, and many times it works by accident (for
>>    example, a NULL pointer added a constant and then derefeced, this
>>    worked because the memory address was legal).
>>    Since the code is big, our strategy is: compile just the parts you
>>    need, debug it enough so that it would run on the PC, and keep the
>>    changes. Hopefully, after enough time, all (or most) of the code
>>    would be runnable on a PC.
>>    We use gcc+gdb to compile and debug the code. In Visual Studio's
>>    cl.exe there are some security checks
>>    <http://msdn.microsoft.com/en-us/library/aa289171(VS.71).aspx> at
>>
>>    run time. This can really assist debugging. For example knowing when
>>    an unintialized variable was used can save you alot of frustration
>>    when trying to figure out why you're getting a wrong numberic results.
>>    My questions are:
>>    1) Are there parallel (or better) runtime security checks for
>>    gcc/gdb? I found the -fstack-protection stack canary switch, but are
>>    there more of this type?
>>    2) What other tools are there which offer similar protection?
>>    Valgrind of course is the first thing that comes to my mind, but
>>    I'll be glad to hear any more ideas.
>>    For example, I would love to be able to get a warning whenever a
>>    pointer is dereferenced twice, where the first time the pointer
>>    points at the memory address of variable x, and the second time it
>>    points to variable y. That way I'll get a warning for the following
>> bug:
>>    int x[3] = {1,2,3};int y[3] = {4,5,6};
>>    int *p = x;
>>    for (int i=0;i<=3;i++,p++) (*p) = (*p)++; // note the <=
>>    3) We use win32 for regular development, so if anyone knows what is
>>    the support for such tests in cygwin/mingw, I'll be glad to hear
>>    about it.
>>
>>    Thanks
>>    Elazar Leibovich
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> _______________________________________________
>> Linux-il mailing list
>> Linux-il at cs.huji.ac.il
>> http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20100112/3dbe4b4e/attachment-0001.html>


More information about the Linux-il mailing list