| Message ID | 20161128123228.30856-10-nix@esperi.org.uk |
|---|---|
| State | New |
| Headers | show |
On 11/28/2016 01:32 PM, Nix wrote: > diff --git a/elf/Makefile b/elf/Makefile > index daf0ebd..7588ca0 100644 > --- a/elf/Makefile > +++ b/elf/Makefile > @@ -775,6 +775,10 @@ $(objpfx)filtmod1.so: $(objpfx)filtmod1.os $(objpfx)filtmod2.so > $< -Wl,-F,$(objpfx)filtmod2.so > $(objpfx)filter: $(objpfx)filtmod1.so > > +# These do not link against libc. > +CFLAGS-filtmod1.c = $(no-stack-protector) > +CFLAGS-filtmod2.c = $(no-stack-protector) Is this really necessary for filtmod2.c? > diff --git a/stdlib/Makefile b/stdlib/Makefile > index 3cce9d9..6d7586e 100644 > --- a/stdlib/Makefile > +++ b/stdlib/Makefile > @@ -187,6 +187,9 @@ LDFLAGS-tst-putenv = $(no-as-needed) > > $(objpfx)tst-putenvmod.so: $(objpfx)tst-putenvmod.os $(link-libc-deps) > $(build-module) > +# This is not only not in libc, it's not even linked with it. > +CFLAGS-tst-putenvmod.c += $(no-stack-protector) I think this papers over an actual failure. Based on my build logs, tst-putenvmod.so is properly linked against libc (including libc_nonshared.a). > diff --git a/sysdeps/x86_64/Makefile b/sysdeps/x86_64/Makefile > index 6d99284..fbe138f 100644 > --- a/sysdeps/x86_64/Makefile > +++ b/sysdeps/x86_64/Makefile > @@ -46,6 +46,9 @@ tests-pie += $(quad-pie-test) > test-extras += tst-quadmod1pie tst-quadmod2pie > extra-test-objs += tst-quadmod1pie.o tst-quadmod2pie.o > > +CFLAGS-tst-quad1pie.c = $(no-stack-protector) > +CFLAGS-tst-quad2pie.c = $(no-stack-protector) This looks like a genuine test failure as well. I'll try to reproduce it, after I have tracked down the more catastrophic MIPS build failure … Thanks, Florian
On 15 Dec 2016, Florian Weimer uttered the following: > On 11/28/2016 01:32 PM, Nix wrote: > >> diff --git a/elf/Makefile b/elf/Makefile >> index daf0ebd..7588ca0 100644 >> --- a/elf/Makefile >> +++ b/elf/Makefile >> @@ -775,6 +775,10 @@ $(objpfx)filtmod1.so: $(objpfx)filtmod1.os $(objpfx)filtmod2.so >> $< -Wl,-F,$(objpfx)filtmod2.so >> $(objpfx)filter: $(objpfx)filtmod1.so >> >> +# These do not link against libc. >> +CFLAGS-filtmod1.c = $(no-stack-protector) >> +CFLAGS-filtmod2.c = $(no-stack-protector) > > Is this really necessary for filtmod2.c? I assumed it was wisest to link it with the same options as the library it was the filter for. It might be harmless, though -- I'll drop it and find out! >> diff --git a/stdlib/Makefile b/stdlib/Makefile >> index 3cce9d9..6d7586e 100644 >> --- a/stdlib/Makefile >> +++ b/stdlib/Makefile >> @@ -187,6 +187,9 @@ LDFLAGS-tst-putenv = $(no-as-needed) >> >> $(objpfx)tst-putenvmod.so: $(objpfx)tst-putenvmod.os $(link-libc-deps) >> $(build-module) >> +# This is not only not in libc, it's not even linked with it. >> +CFLAGS-tst-putenvmod.c += $(no-stack-protector) > > I think this papers over an actual failure. Based on my build logs, > tst-putenvmod.so is properly linked against libc (including > libc_nonshared.a). Hmm! I'll take that out and have a look. Maybe __attribute ((constructor)) is causing problems, though I'd assume this would work fine or other stack-protector users would be howling. Much of this may be residual fallout from the days before we had the stack-protector symbol export from libc/internal refs inside libc working right. >> diff --git a/sysdeps/x86_64/Makefile b/sysdeps/x86_64/Makefile >> index 6d99284..fbe138f 100644 >> --- a/sysdeps/x86_64/Makefile >> +++ b/sysdeps/x86_64/Makefile >> @@ -46,6 +46,9 @@ tests-pie += $(quad-pie-test) >> test-extras += tst-quadmod1pie tst-quadmod2pie >> extra-test-objs += tst-quadmod1pie.o tst-quadmod2pie.o >> >> +CFLAGS-tst-quad1pie.c = $(no-stack-protector) >> +CFLAGS-tst-quad2pie.c = $(no-stack-protector) > > This looks like a genuine test failure as well. I'll try to reproduce it, after I have tracked down the more catastrophic MIPS > build failure … Yeah: they link against libc as well. Maybe I was misled by an old-binutils problem back in the early days of this patch. I'll try pulling this out as well... (the MIPS one is easily explained by my not having a MIPS available and having done zero testing on it. God only knows what system-dependent horrors we need to work around. I haven't even *used* a MIPS bigger than my wifi router since the early '90s... :) )
On 12/15/2016 03:54 PM, Nix wrote: > On 15 Dec 2016, Florian Weimer uttered the following: > >> On 11/28/2016 01:32 PM, Nix wrote: >> >>> diff --git a/elf/Makefile b/elf/Makefile >>> index daf0ebd..7588ca0 100644 >>> --- a/elf/Makefile >>> +++ b/elf/Makefile >>> @@ -775,6 +775,10 @@ $(objpfx)filtmod1.so: $(objpfx)filtmod1.os $(objpfx)filtmod2.so >>> $< -Wl,-F,$(objpfx)filtmod2.so >>> $(objpfx)filter: $(objpfx)filtmod1.so >>> >>> +# These do not link against libc. >>> +CFLAGS-filtmod1.c = $(no-stack-protector) >>> +CFLAGS-filtmod2.c = $(no-stack-protector) >> >> Is this really necessary for filtmod2.c? > > I assumed it was wisest to link it with the same options as the library > it was the filter for. It might be harmless, though -- I'll drop it and > find out! > >>> diff --git a/stdlib/Makefile b/stdlib/Makefile >>> index 3cce9d9..6d7586e 100644 >>> --- a/stdlib/Makefile >>> +++ b/stdlib/Makefile >>> @@ -187,6 +187,9 @@ LDFLAGS-tst-putenv = $(no-as-needed) >>> >>> $(objpfx)tst-putenvmod.so: $(objpfx)tst-putenvmod.os $(link-libc-deps) >>> $(build-module) >>> +# This is not only not in libc, it's not even linked with it. >>> +CFLAGS-tst-putenvmod.c += $(no-stack-protector) >> >> I think this papers over an actual failure. Based on my build logs, >> tst-putenvmod.so is properly linked against libc (including >> libc_nonshared.a). > > Hmm! I'll take that out and have a look. Maybe __attribute > ((constructor)) is causing problems, though I'd assume this would work > fine or other stack-protector users would be howling. > > Much of this may be residual fallout from the days before we had the > stack-protector symbol export from libc/internal refs inside libc > working right. > >>> diff --git a/sysdeps/x86_64/Makefile b/sysdeps/x86_64/Makefile >>> index 6d99284..fbe138f 100644 >>> --- a/sysdeps/x86_64/Makefile >>> +++ b/sysdeps/x86_64/Makefile >>> @@ -46,6 +46,9 @@ tests-pie += $(quad-pie-test) >>> test-extras += tst-quadmod1pie tst-quadmod2pie >>> extra-test-objs += tst-quadmod1pie.o tst-quadmod2pie.o >>> >>> +CFLAGS-tst-quad1pie.c = $(no-stack-protector) >>> +CFLAGS-tst-quad2pie.c = $(no-stack-protector) >> >> This looks like a genuine test failure as well. I'll try to reproduce it, after I have tracked down the more catastrophic MIPS >> build failure … > > Yeah: they link against libc as well. Maybe I was misled by an > old-binutils problem back in the early days of this patch. > > I'll try pulling this out as well... > > (the MIPS one is easily explained by my not having a MIPS available and > having done zero testing on it. God only knows what system-dependent > horrors we need to work around. I haven't even *used* a MIPS bigger than > my wifi router since the early '90s... :) ) Joseph added build-many-glibcs.py recently, which really helps diagnosing build-time failures and ABI issues. The MIPS failure appears to be similar to the ia64 failure because the R_MIPS_CALL16 relocation in __stack_chk_fail_local triggers it: 000f4590 <__stack_chk_fail_local>: f4590: 27bdfff0 addiu sp,sp,-16 f4594: ffbc0000 sd gp,0(sp) f4598: 3c1c0000 lui gp,0x0 f4598: R_MIPS_GPREL16 __stack_chk_fail_local f4598: R_MIPS_SUB *ABS* f4598: R_MIPS_HI16 *ABS* f459c: 0399e021 addu gp,gp,t9 f45a0: 279c0000 addiu gp,gp,0 f45a0: R_MIPS_GPREL16 __stack_chk_fail_local f45a0: R_MIPS_SUB *ABS* f45a0: R_MIPS_LO16 *ABS* f45a4: 8f990000 lw t9,0(gp) f45a4: R_MIPS_CALL16 .text+0xf4590 f45a8: ffbf0008 sd ra,8(sp) f45ac: 0320f809 jalr t9 f45ac: R_MIPS_JALR __stack_chk_fail f45b0: 00000000 nop So I'll construct a new series with your STACK_PROTECTOR_LEVEL patch and see where things go with that. Thanks, Florian
On 15 Dec 2016, Florian Weimer uttered the following:
> So I'll construct a new series with your STACK_PROTECTOR_LEVEL patch and see where things go with that.
I'll throw everything you proposed together into a new series and throw
my full test cycle at it too.
diff --git a/elf/Makefile b/elf/Makefile index daf0ebd..7588ca0 100644 --- a/elf/Makefile +++ b/elf/Makefile @@ -775,6 +775,10 @@ $(objpfx)filtmod1.so: $(objpfx)filtmod1.os $(objpfx)filtmod2.so $< -Wl,-F,$(objpfx)filtmod2.so $(objpfx)filter: $(objpfx)filtmod1.so +# These do not link against libc. +CFLAGS-filtmod1.c = $(no-stack-protector) +CFLAGS-filtmod2.c = $(no-stack-protector) + $(objpfx)unload: $(libdl) $(objpfx)unload.out: $(objpfx)unloadmod.so diff --git a/stdlib/Makefile b/stdlib/Makefile index 3cce9d9..6d7586e 100644 --- a/stdlib/Makefile +++ b/stdlib/Makefile @@ -187,6 +187,9 @@ LDFLAGS-tst-putenv = $(no-as-needed) $(objpfx)tst-putenvmod.so: $(objpfx)tst-putenvmod.os $(link-libc-deps) $(build-module) +# This is not only not in libc, it's not even linked with it. +CFLAGS-tst-putenvmod.c += $(no-stack-protector) + libof-tst-putenvmod = extramodules $(objpfx)bug-getcontext: $(libm) diff --git a/sysdeps/x86_64/Makefile b/sysdeps/x86_64/Makefile index 6d99284..fbe138f 100644 --- a/sysdeps/x86_64/Makefile +++ b/sysdeps/x86_64/Makefile @@ -46,6 +46,9 @@ tests-pie += $(quad-pie-test) test-extras += tst-quadmod1pie tst-quadmod2pie extra-test-objs += tst-quadmod1pie.o tst-quadmod2pie.o +CFLAGS-tst-quad1pie.c = $(no-stack-protector) +CFLAGS-tst-quad2pie.c = $(no-stack-protector) + $(objpfx)tst-quad1pie: $(objpfx)tst-quadmod1pie.o $(objpfx)tst-quad2pie: $(objpfx)tst-quadmod2pie.o
From: Nick Alcock <nick.alcock@oracle.com> These tests do not link with libc, so cannot see __stack_chk_fail(). v3: Use $(no-stack-protector). * elf/Makefile (CFLAGS-filtmod1.c): Use $(no-stack-protector) for non-libc-linking testcase. (CFLAGS-filtmod2.c): Likewise. * stdlib/Makefile (CFLAGS-tst-putenvmod.c): Likewise. * sysdeps/x86_64/Makefile (CFLAGS-tst-quad1pie.c): Likewise. (CFLAGS-tst-quad2pie.c): Likewise. --- elf/Makefile | 4 ++++ stdlib/Makefile | 3 +++ sysdeps/x86_64/Makefile | 3 +++ 3 files changed, 10 insertions(+)