Re: glibc-2.4 __stack_chk_guard/__pointer_chk_guard

[Hamish Greig <hgreig at bigpond dot net dot au>]

On Monday 03 April 2006 19:35, Peter S. Mazinger wrote:
> On Mon, 3 Apr 2006, Hamish Greig wrote:
> > On Tuesday 07 March 2006 20:47, Roland McGrath wrote:
> > > There is indeed no present problem.  The linker behavior does the right
> > > thing implicitly.  That right thing is a potential gotcha for
> > > accidental changes in the future.  i.e., if you do introduce the symbol
> > > in the future on some configuration, then you need to make sure that it
> > > gets into a newer version set so that configuration's ABI version
> > > dependencies work right. But uglifying the sources further to avoid the
> > > symbol appearing in the version script is no less error-prone. 
> > > Instead, we rely on checking the resultant dynamic symbol lists to
> > > watch out for such stray symbols.
> >
> > Building glibc-2.4 with gcc-4.1 I found two things that I thought might
> > be related to this. Apologies if I am mistaken.
> >
> > gcc-4.1 checks if glibc supports ssp and if yes, doesn't add -lssp* to
> > the fstack-protector specs. So nscd fails to build when gcc has been
> > built against glibc2.4, unless I add -lssp to the nscd Makefile rules or
> > manually change the gcc's specs.
>
> You shouldn't need -lssp, if glibc has ssp support builtin, the trouble in
> the whole glibc tree is that it needs to link against
> libc_nonshared.a and ld-linux.so.2 as well, else you will miss
> __stack_chk_guard/__stack_chk_fail (true for all non-libc.so libs as well)
> The best way would be to set up the libc.so linker script for
> glibc internal links earlier so that everything automatically links
> against libc.so.6/libc_nonshared.a/ld-linux.so.2 and use that everywhere
> instead of the hardcoded libc.so.6 only.
>
> > The second thing I noticed is when I specify -disable-ssp in gcc's
> > configure nothing on my system exports __stack_ghk_guard (normally in
> > libssp and libssp_nonshared), and compiling nscd  fails unless I force
> > the
> > stack-protector check in glibc's configure (libc_cv_ssp) to fail.
>
> __stack_chk_guard can also come from glibc's ld-linux.so.2 (but only if
> TLS is not supported on your arch) or libc.a.
>
> > I have got to this point and without being a programmer I am stuck where
> > to go from here, whether glibc's __stack_chk_fail and gcc's
> > __stack_chk_guard  are different implementations of the same thing or if
> > I need to file a bug (for glibc or gcc or both) or fix/ adjust my build
> > system.
>
> they are different, __stack_chk_guard is the guard/canary itself,
> __stack_chk_fail is the function that reports it.
>
> Peter

Thanks, I'll look into all those things.
Something is definitely not working on my system as libc.a only has 
stack_chk_fail(_local), but gcc defines my glibc as having ssp.

nm /usr/lib/libc.a | grep stack_chk

stack_chk_fail.o:
00000000 T __stack_chk_fail
stack_chk_fail_local.o:
         U __stack_chk_fail
00000000 T __stack_chk_fail_local

Thanks for the new direction.

Hamish Greig