Stack smash protection: Automated (de)bugging?

[Erik Christiansen]

On Tue, Jul 11, 2006 at 07:55:39PM -0400, John Richard Moser wrote:
> 
> I gotta figure out how to get gcc-4.1.1/gcc/targhooks.c to spit out
> basically __stack_chk_fail2(__FUNC__,__FILE__,__guard) instead of
> __stack_chk_fail(), is what I mean.  Really curious to how this thing
> works, basically I'm staring at the code hoping it'll write itself or
> something XD

Short of quickly scripting a global replacement of these calls in the
source, a conventional way to approach this is to use the " --wrap
symbol" facility in the linker. (man ld elucidates via an example, to
make things easier.)

The linker then replaces all __stack_chk_fail() calls with
__stack_chk_fail2(), which is your wrapper function. Normally, extra
paramaters can then be generated in the wrapper. This works fine for
"system" type calls, where any additional gumpf comes from global scope.

But you want to add __FILE__, which would require a wrapper function per
file. i.e. Link time wrapping is too late for your case.

Frankly, it seems quicker to pass all the source files through a brief
awk script, replacing all invocations of __stack_chk_fail() to the
desired form. (Perhaps because that's what I usually do. ;-)

> Once that's done gcc is fine, upstream looks willing (if a little
> reluctant) to take a patch if I can supply one, and I have chosen a
> strategy that will avoid ABI breakage (keep __stack_chk_fail() and add a
> new handler, so old protected code stays binary compatible).

Would the patch provide general compile-time wrapping? Would you
maintain naming form consistency with the linker?

> 
>     Creative brains are a valuable, limited resource. They shouldn't be
>     wasted on re-inventing the wheel when there are so many fascinating
>     new problems waiting out there.
>                                                  -- Eric Steven Raymond

Yep, re-using the linker nomenclature would be a good step in that
direction.


Erik