2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Miles Lane]

I am getting this:

  KLIBCLD usr/klibc/libc.so
usr/klibc/execl.o: In function `execl':
usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
usr/klibc/execle.o: In function `execle':
usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
usr/klibc/execvpe.o: In function `execvpe':
usr/klibc/execvpe.c:75: undefined reference to `__stack_chk_fail'
usr/klibc/execlp.o: In function `execlp':
usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
usr/klibc/execlpe.o: In function `execlpe':
usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
usr/klibc/vfprintf.o:usr/klibc/vfprintf.c:26: more undefined
references to `__stack_chk_fail' follow
make[2]: *** [usr/klibc/libc.so] Error 1

But I've searched all the .h and .c files in the tree and found no
reference to __stack_chk_fail.  I am running Ubuntu's Edgy Eft (the
latest development tree).

Thanks,
              Miles

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Arjan van de Ven]

On Sat, 2006-07-01 at 14:09 -0700, Miles Lane wrote:
> I am getting this:
> 
>   KLIBCLD usr/klibc/libc.so
> usr/klibc/execl.o: In function `execl':
> usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> usr/klibc/execle.o: In function `execle':
> usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> usr/klibc/execvpe.o: In function `execvpe':
> usr/klibc/execvpe.c:75: undefined reference to `__stack_chk_fail'
> usr/klibc/execlp.o: In function `execlp':
> usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> usr/klibc/execlpe.o: In function `execlpe':
> usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> usr/klibc/vfprintf.o:usr/klibc/vfprintf.c:26: more undefined
> references to `__stack_chk_fail' follow
> make[2]: *** [usr/klibc/libc.so] Error 1
> 
> But I've searched all the .h and .c files in the tree and found no
> reference to __stack_chk_fail.  I am running Ubuntu's Edgy Eft (the
> latest development tree).

somehow you're getting -fstack-protector added to your CFLAGs.. which
won't do you any good unless you link to glibc or another library that
implements the user side of the feature...

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Miles Lane]

On 7/1/06, Arjan van de Ven <arjan@infradead.org> wrote:
> On Sat, 2006-07-01 at 14:09 -0700, Miles Lane wrote:
> > I am getting this:
> >
> >   KLIBCLD usr/klibc/libc.so
> > usr/klibc/execl.o: In function `execl':
> > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > usr/klibc/execle.o: In function `execle':
> > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > usr/klibc/execvpe.o: In function `execvpe':
> > usr/klibc/execvpe.c:75: undefined reference to `__stack_chk_fail'
> > usr/klibc/execlp.o: In function `execlp':
> > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > usr/klibc/execlpe.o: In function `execlpe':
> > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > usr/klibc/vfprintf.o:usr/klibc/vfprintf.c:26: more undefined
> > references to `__stack_chk_fail' follow
> > make[2]: *** [usr/klibc/libc.so] Error 1
> >
> > But I've searched all the .h and .c files in the tree and found no
> > reference to __stack_chk_fail.  I am running Ubuntu's Edgy Eft (the
> > latest development tree).
>
> somehow you're getting -fstack-protector added to your CFLAGs.. which
> won't do you any good unless you link to glibc or another library that
> implements the user side of the feature...

The only reference to -fstack-protector in my linux kernel tree is here:

arch/i386/kernel/asm-offsets.s

        .file   "asm-offsets.c"
# GNU C version 4.1.2 20060613 (prerelease) (Ubuntu 4.1.1-2ubuntu5)
(i486-linux-gnu)
#       compiled by GNU C version 4.1.2 20060613 (prerelease) (Ubuntu
4.1.1-2ubuntu5).
# GGC heuristics: --param ggc-min-expand=96 --param ggc-min-heapsize=125021
# options passed:  -nostdinc -Iinclude -Iinclude/asm-i386/mach-default
# -D__KERNEL__ -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(asm_offsets)
# -DKBUILD_MODNAME=KBUILD_STR(asm_offsets) -isystem -include -MD -m32
# -msoft-float -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium4
# -mregparm=3 -auxbase-strip -Os -Wall -Wundef -Wstrict-prototypes
# -Wno-trigraphs -Wdeclaration-after-statement -Wno-pointer-sign
# -fno-strict-aliasing -fno-common -fno-omit-frame-pointer
# -fno-optimize-sibling-calls -fasynchronous-unwind-tables -ffreestanding
# -fverbose-asm
# options enabled:  -falign-loops -fargument-alias
# -fasynchronous-unwind-tables -fbranch-count-reg -fcaller-saves
# -fcprop-registers -fcrossjumping -fcse-follow-jumps -fcse-skip-blocks
# -fdefer-pop -fdelete-null-pointer-checks -fearly-inlining
# -feliminate-unused-debug-types -fexpensive-optimizations -ffunction-cse
# -fgcse -fgcse-lm -fguess-branch-probability -fident -fif-conversion
# -fif-conversion2 -finline-functions -finline-functions-called-once
# -fipa-pure-const -fipa-reference -fipa-type-escape -fivopts
# -fkeep-static-consts -fleading-underscore -floop-optimize
# -floop-optimize2 -fmath-errno -fmerge-constants -foptimize-register-move
# -fpcc-struct-return -fpeephole -fpeephole2 -fregmove -freorder-functions
# -frerun-cse-after-loop -frerun-loop-opt -fsched-interblock -fsched-spec
# -fsched-stalled-insns-dep -fshow-column -fsplit-ivs-in-unroller
# -fstack-protector -fstrength-reduce -fthread-jumps -ftrapping-math
# -ftree-ccp -ftree-copy-prop -ftree-copyrename -ftree-dce
# -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im
# -ftree-loop-ivcanon -ftree-loop-optimize -ftree-lrs -ftree-salias
# -ftree-sink -ftree-sra -ftree-store-ccp -ftree-store-copy-prop -ftree-ter
# -ftree-vect-loop-version -ftree-vrp -funit-at-a-time -funwind-tables
# -fverbose-asm -fzero-initialized-in-bss -m32 -m96bit-long-double
# -malign-stringops -mieee-fp -mno-fancy-math-387 -mno-red-zone -mpush-args
# -mtls-direct-seg-refs

# Compiler executable checksum: 08eb10034110f95d4c3c06297525c871

        .text
.globl foo
        .type   foo, @function
foo:
.LFB517:
        pushl   %ebp    #
.LCFI0:
        movl    %esp, %ebp      #,
.LCFI1:
#APP

->SIGCONTEXT_eax $44 offsetof(struct sigcontext, eax)   #

->SIGCONTEXT_ebx $32 offsetof(struct sigcontext, ebx)   #

->SIGCONTEXT_ecx $40 offsetof(struct sigcontext, ecx)   #

->SIGCONTEXT_edx $36 offsetof(struct sigcontext, edx)   #

->SIGCONTEXT_esi $20 offsetof(struct sigcontext, esi)   #

->SIGCONTEXT_edi $16 offsetof(struct sigcontext, edi)   #

->SIGCONTEXT_ebp $24 offsetof(struct sigcontext, ebp)   #

->SIGCONTEXT_esp $28 offsetof(struct sigcontext, esp)   #

->SIGCONTEXT_eip $56 offsetof(struct sigcontext, eip)   #

->

->CPUINFO_x86 $0 offsetof(struct cpuinfo_x86, x86)      #

->CPUINFO_x86_vendor $1 offsetof(struct cpuinfo_x86, x86_vendor)        #

->CPUINFO_x86_model $2 offsetof(struct cpuinfo_x86, x86_model)  #

->CPUINFO_x86_mask $3 offsetof(struct cpuinfo_x86, x86_mask)    #

->CPUINFO_hard_math $6 offsetof(struct cpuinfo_x86, hard_math)  #

->CPUINFO_cpuid_level $8 offsetof(struct cpuinfo_x86, cpuid_level)      #

->CPUINFO_x86_capability $12 offsetof(struct cpuinfo_x86,
x86_capability)       #

->CPUINFO_x86_vendor_id $40 offsetof(struct cpuinfo_x86, x86_vendor_id) #

->

->TI_task $0 offsetof(struct thread_info, task) #

->TI_exec_domain $4 offsetof(struct thread_info, exec_domain)   #

->TI_flags $8 offsetof(struct thread_info, flags)       #

->TI_status $12 offsetof(struct thread_info, status)    #

->TI_cpu $16 offsetof(struct thread_info, cpu)  #

->TI_preempt_count $20 offsetof(struct thread_info, preempt_count)      #

->TI_addr_limit $24 offsetof(struct thread_info, addr_limit)    #

->TI_restart_block $32 offsetof(struct thread_info, restart_block)      #

->TI_sysenter_return $28 offsetof(struct thread_info, sysenter_return)  #

->

->EXEC_DOMAIN_handler $4 offsetof(struct exec_domain, handler)  #

->RT_SIGFRAME_sigcontext $164 offsetof(struct rt_sigframe,
uc.uc_mcontext)      #

->

->pbe_address $0 offsetof(struct pbe, address)  #

->pbe_orig_address $4 offsetof(struct pbe, orig_address)        #

->pbe_next $8 offsetof(struct pbe, next)        #

->TSS_sysenter_esp0 $-8700 offsetof(struct tss_struct, esp0) -
sizeof(struct tss_struct)        #

->PAGE_SIZE_asm $4096 PAGE_SIZE #

->VDSO_PRELINK $-8192 VDSO_PRELINK      #

->crypto_tfm_ctx_offset $48 offsetof(struct crypto_tfm, __crt_ctx)      #
#NO_APP
        popl    %ebp    #
        ret
.LFE517:
        .size   foo, .-foo
        .section        .eh_frame,"a",@progbits
.Lframe1:
        .long   .LECIE1-.LSCIE1
.LSCIE1:
        .long   0x0
        .byte   0x1
        .string ""
        .uleb128 0x1
        .sleb128 -4
        .byte   0x8
        .byte   0xc
        .uleb128 0x4
        .uleb128 0x4
        .byte   0x88
        .uleb128 0x1
        .align 4
.LECIE1:
.LSFDE1:
        .long   .LEFDE1-.LASFDE1
.LASFDE1:
        .long   .LASFDE1-.Lframe1
        .long   .LFB517
        .long   .LFE517-.LFB517
        .byte   0x4
        .long   .LCFI0-.LFB517
        .byte   0xe
        .uleb128 0x8
        .byte   0x85
        .uleb128 0x2
        .byte   0x4
        .long   .LCFI1-.LCFI0
        .byte   0xd
        .uleb128 0x5
        .align 4
.LEFDE1:
        .ident  "GCC: (GNU) 4.1.2 20060613 (prerelease) (Ubuntu 4.1.1-2ubuntu5)"
        .section        .note.GNU-stack,"",@progbits

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Arjan van de Ven]

On Sat, 2006-07-01 at 14:25 -0700, Miles Lane wrote:
> On 7/1/06, Arjan van de Ven <arjan@infradead.org> wrote:
> > On Sat, 2006-07-01 at 14:09 -0700, Miles Lane wrote:
> > > I am getting this:
> > >
> > >   KLIBCLD usr/klibc/libc.so
> > > usr/klibc/execl.o: In function `execl':
> > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > usr/klibc/execle.o: In function `execle':
> > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > usr/klibc/execvpe.o: In function `execvpe':
> > > usr/klibc/execvpe.c:75: undefined reference to `__stack_chk_fail'
> > > usr/klibc/execlp.o: In function `execlp':
> > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > usr/klibc/execlpe.o: In function `execlpe':
> > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > usr/klibc/vfprintf.o:usr/klibc/vfprintf.c:26: more undefined
> > > references to `__stack_chk_fail' follow
> > > make[2]: *** [usr/klibc/libc.so] Error 1
> > >
> > > But I've searched all the .h and .c files in the tree and found no
> > > reference to __stack_chk_fail.  I am running Ubuntu's Edgy Eft (the
> > > latest development tree).
> >
> > somehow you're getting -fstack-protector added to your CFLAGs.. which
> > won't do you any good unless you link to glibc or another library that
> > implements the user side of the feature...
> 
> The only reference to -fstack-protector in my linux kernel tree is here:


try looking at your CFLAGS environment variable.. that may get
inherited ;)

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Miles Lane]

On 7/1/06, Arjan van de Ven <arjan@infradead.org> wrote:
> On Sat, 2006-07-01 at 14:25 -0700, Miles Lane wrote:
> > On 7/1/06, Arjan van de Ven <arjan@infradead.org> wrote:
> > > On Sat, 2006-07-01 at 14:09 -0700, Miles Lane wrote:
> > > > I am getting this:
> > > >
> > > >   KLIBCLD usr/klibc/libc.so
> > > > usr/klibc/execl.o: In function `execl':
> > > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > > usr/klibc/execle.o: In function `execle':
> > > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > > usr/klibc/execvpe.o: In function `execvpe':
> > > > usr/klibc/execvpe.c:75: undefined reference to `__stack_chk_fail'
> > > > usr/klibc/execlp.o: In function `execlp':
> > > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > > usr/klibc/execlpe.o: In function `execlpe':
> > > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > > usr/klibc/vfprintf.o:usr/klibc/vfprintf.c:26: more undefined
> > > > references to `__stack_chk_fail' follow
> > > > make[2]: *** [usr/klibc/libc.so] Error 1
> > > >
> > > > But I've searched all the .h and .c files in the tree and found no
> > > > reference to __stack_chk_fail.  I am running Ubuntu's Edgy Eft (the
> > > > latest development tree).
> > >
> > > somehow you're getting -fstack-protector added to your CFLAGs.. which
> > > won't do you any good unless you link to glibc or another library that
> > > implements the user side of the feature...
> >
> > The only reference to -fstack-protector in my linux kernel tree is here:
>
>
> try looking at your CFLAGS environment variable.. that may get
> inherited ;)

https://wiki.ubuntu.com/GccSsp

It appears that Ubuntu's Edgy Eft (the development tree) now contains
"Stack Smashing Protection" enabled by default.  I found a web page
that states that -fno-stack-protector can be used to disable this
functionality.  Interestingly, another web page stated that SSP has
been enabled in Redhat compilers for a long time and is now also
enabled in Debian SID.  Perhaps -fno-stack-protector should be added
to the kernel build be default?

Thanks,
         Miles

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Miles Lane]

On 7/1/06, Miles Lane <miles.lane@gmail.com> wrote:
> On 7/1/06, Arjan van de Ven <arjan@infradead.org> wrote:
> > On Sat, 2006-07-01 at 14:25 -0700, Miles Lane wrote:
> > > On 7/1/06, Arjan van de Ven <arjan@infradead.org> wrote:
> > > > On Sat, 2006-07-01 at 14:09 -0700, Miles Lane wrote:
> > > > > I am getting this:
> > > > >
> > > > >   KLIBCLD usr/klibc/libc.so
> > > > > usr/klibc/execl.o: In function `execl':
> > > > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > > > usr/klibc/execle.o: In function `execle':
> > > > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > > > usr/klibc/execvpe.o: In function `execvpe':
> > > > > usr/klibc/execvpe.c:75: undefined reference to `__stack_chk_fail'
> > > > > usr/klibc/execlp.o: In function `execlp':
> > > > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > > > usr/klibc/execlpe.o: In function `execlpe':
> > > > > usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'
> > > > > usr/klibc/vfprintf.o:usr/klibc/vfprintf.c:26: more undefined
> > > > > references to `__stack_chk_fail' follow
> > > > > make[2]: *** [usr/klibc/libc.so] Error 1
> > > > >
> > > > > But I've searched all the .h and .c files in the tree and found no
> > > > > reference to __stack_chk_fail.  I am running Ubuntu's Edgy Eft (the
> > > > > latest development tree).
> > > >
> > > > somehow you're getting -fstack-protector added to your CFLAGs.. which
> > > > won't do you any good unless you link to glibc or another library that
> > > > implements the user side of the feature...
> > >
> > > The only reference to -fstack-protector in my linux kernel tree is here:
> >
> >
> > try looking at your CFLAGS environment variable.. that may get
> > inherited ;)
>
> https://wiki.ubuntu.com/GccSsp
>
> It appears that Ubuntu's Edgy Eft (the development tree) now contains
> "Stack Smashing Protection" enabled by default.  I found a web page
> that states that -fno-stack-protector can be used to disable this
> functionality.  Interestingly, another web page stated that SSP has
> been enabled in Redhat compilers for a long time and is now also
> enabled in Debian SID.  Perhaps -fno-stack-protector should be added
> to the kernel build be default?

Darn it.  I don't seem to know how to get -fno-stack-protector to
work.  I ran:
export CFLAGS=-fno-stack-protector
make mrproper
cp ../.config .
make oldconfig
CFLAGS=-fno-stack-protector make all install modules modules_install

But I am still getting the errors.  Anyone know what I am doing wrong?

Thanks,
        Miles

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Sam Ravnborg]

 >> > > >
> >> > > >   KLIBCLD usr/klibc/libc.so
> >> > > > usr/klibc/execl.o: In function `execl':
...
 >
> >https://wiki.ubuntu.com/GccSsp
> >
> >It appears that Ubuntu's Edgy Eft (the development tree) now contains
> >"Stack Smashing Protection" enabled by default.  I found a web page
> >that states that -fno-stack-protector can be used to disable this
> >functionality.  Interestingly, another web page stated that SSP has
> >been enabled in Redhat compilers for a long time and is now also
> >enabled in Debian SID.  Perhaps -fno-stack-protector should be added
> >to the kernel build be default?
> 
> Darn it.  I don't seem to know how to get -fno-stack-protector to
> work.  I ran:
> export CFLAGS=-fno-stack-protector
> make mrproper
> cp ../.config .
> make oldconfig
> CFLAGS=-fno-stack-protector make all install modules modules_install
> 
> But I am still getting the errors.  Anyone know what I am doing wrong?

For klibc you need to patch scripts/Kbuild.klibc

Appending it to KLIBCWARNFLAGS seems the right place.

Do you know from what gcc version we can start using -fno-stack-protector?

	Sam

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[H. Peter Anvin]

Sam Ravnborg wrote:
> 
> For klibc you need to patch scripts/Kbuild.klibc
> 
> Appending it to KLIBCWARNFLAGS seems the right place.

KLIBCREQFLAGS, rather.

> Do you know from what gcc version we can start using -fno-stack-protector?

Isn't there a macro to test if gcc supports a specific option already?

Either way, I can also add __stack_chk_fail() as an alias for abort(), 
for people who actually want the feature.

	-hpa

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[H. Peter Anvin]

H. Peter Anvin wrote:
> Sam Ravnborg wrote:
>>
>> For klibc you need to patch scripts/Kbuild.klibc
>>
>> Appending it to KLIBCWARNFLAGS seems the right place.
> 
> KLIBCREQFLAGS, rather.
> 
>> Do you know from what gcc version we can start using 
>> -fno-stack-protector?
> 
> Isn't there a macro to test if gcc supports a specific option already?
> 
> Either way, I can also add __stack_chk_fail() as an alias for abort(), 
> for people who actually want the feature.
> 

I looked at it again, and it looks like gcc depends on the TLS ABI in 
order to pick the value of the cookie.  That makes it a potentially lot 
more cantankerous option; I would like to be able to support stack-smash 
checking in klibc, but if it means implementing TLS on all 
architectures, then that would really defeat the purpose (and we should 
add -fno-stack-protector to KLIBCREQFLAGS.)

Arjan: I see a few stack-protector-related have your name on it, do you 
have any details on implementation constraints for this across 
architectures?

	-hpa

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Miles Lane]

On 7/1/06, Sam Ravnborg <sam@ravnborg.org> wrote:
>  >> > > >
> > >> > > >   KLIBCLD usr/klibc/libc.so
> > >> > > > usr/klibc/execl.o: In function `execl':
> ...
>  >
> > >https://wiki.ubuntu.com/GccSsp
> > >
> > >It appears that Ubuntu's Edgy Eft (the development tree) now contains
> > >"Stack Smashing Protection" enabled by default.  I found a web page
> > >that states that -fno-stack-protector can be used to disable this
> > >functionality.  Interestingly, another web page stated that SSP has
> > >been enabled in Redhat compilers for a long time and is now also
> > >enabled in Debian SID.  Perhaps -fno-stack-protector should be added
> > >to the kernel build be default?
> >
> > Darn it.  I don't seem to know how to get -fno-stack-protector to
> > work.  I ran:
> > export CFLAGS=-fno-stack-protector
> > make mrproper
> > cp ../.config .
> > make oldconfig
> > CFLAGS=-fno-stack-protector make all install modules modules_install
> >
> > But I am still getting the errors.  Anyone know what I am doing wrong?
>
> For klibc you need to patch scripts/Kbuild.klibc
>
> Appending it to KLIBCWARNFLAGS seems the right place.
>
> Do you know from what gcc version we can start using -fno-stack-protector?

This fixed is for me.  Andrew, would this be appropriate to merge into
your tree?

--- scripts/Kbuild.klibc.old    2006-07-01 16:32:55.000000000 -0700
+++ scripts/Kbuild.klibc        2006-07-01 16:28:59.000000000 -0700
@@ -51,7 +51,7 @@
 KLIBCREQFLAGS     :=
 KLIBCARCHREQFLAGS :=
 KLIBCOPTFLAGS     :=
-KLIBCWARNFLAGS    := -W -Wall -Wno-sign-compare -Wno-unused-parameter
+KLIBCWARNFLAGS    := -W -Wall -Wno-sign-compare -Wno-unused-parameter
-fno-stack-protector
 KLIBCSHAREDFLAGS  :=
 KLIBCBITSIZE      :=
 KLIBCLDFLAGS      :=

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[H. Peter Anvin]

[-- Attachment #1: Type: text/plain, Size: 316 bytes --]

Sam Ravnborg wrote:
> 
> For klibc you need to patch scripts/Kbuild.klibc
> 
> Appending it to KLIBCWARNFLAGS seems the right place.
> 
> Do you know from what gcc version we can start using -fno-stack-protector?
> 

Here is a patch for klibc.  Miles, could you try it out and see if it 
does what you need?

	-hpa


[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 967 bytes --]

diff --git a/scripts/Kbuild.klibc b/scripts/Kbuild.klibc
index ac0439e..d30ada2 100644
--- a/scripts/Kbuild.klibc
+++ b/scripts/Kbuild.klibc
@@ -48,7 +48,7 @@ include $(srctree)/scripts/Kbuild.includ
 # Defines used when compiling early userspace (klibc programs)
 # ---------------------------------------------------------------------------
 
-KLIBCREQFLAGS     :=
+KLIBCREQFLAGS     := $(call cc_option, -fno-stack-protector, )
 KLIBCARCHREQFLAGS :=
 KLIBCOPTFLAGS     :=
 KLIBCWARNFLAGS    := -W -Wall -Wno-sign-compare -Wno-unused-parameter
diff --git a/usr/klibc/arch/arm/MCONFIG b/usr/klibc/arch/arm/MCONFIG
index 0023eee..fa3ada2 100644
--- a/usr/klibc/arch/arm/MCONFIG
+++ b/usr/klibc/arch/arm/MCONFIG
@@ -12,7 +12,7 @@ CPU_TUNE := strongarm
 
 KLIBCOPTFLAGS = -Os -march=$(CPU_ARCH) -mtune=$(CPU_TUNE)
 KLIBCBITSIZE  = 32
-KLIBCREQFLAGS = -fno-exceptions
+KLIBCREQFLAGS += -fno-exceptions
 KLIBCSTRIPFLAGS += -R .ARM.exidx
 
 ifeq ($(CONFIG_KLIBC_THUMB),y)

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Sam Ravnborg]

On Sat, Jul 01, 2006 at 04:35:32PM -0700, H. Peter Anvin wrote:
> Sam Ravnborg wrote:
> >
> >For klibc you need to patch scripts/Kbuild.klibc
> >
> >Appending it to KLIBCWARNFLAGS seems the right place.
> >
> >Do you know from what gcc version we can start using -fno-stack-protector?
> >
> 
> Here is a patch for klibc.  Miles, could you try it out and see if it 
> does what you need?
> 
> 	-hpa
> 
  
> -KLIBCREQFLAGS     :=
> +KLIBCREQFLAGS     := $(call cc_option, -fno-stack-protector, )

This needs to be $(call cc-option, ...)
'-' not '_'.

> +++ b/usr/klibc/arch/arm/MCONFIG
> @@ -12,7 +12,7 @@ CPU_TUNE := strongarm
>  
>  KLIBCOPTFLAGS = -Os -march=$(CPU_ARCH) -mtune=$(CPU_TUNE)
>  KLIBCBITSIZE  = 32
> -KLIBCREQFLAGS = -fno-exceptions
> +KLIBCREQFLAGS += -fno-exceptions

This should be fixed for KLIBCOPTFLAGS also. Unrelated to this issue.

	Sam

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[H. Peter Anvin]

Sam Ravnborg wrote:
>   
>> -KLIBCREQFLAGS     :=
>> +KLIBCREQFLAGS     := $(call cc_option, -fno-stack-protector, )
> 
> This needs to be $(call cc-option, ...)
> '-' not '_'.
> 

*plonk* OK... I feel dumb now :)

Miles: could you try this out?

>> +++ b/usr/klibc/arch/arm/MCONFIG
>> @@ -12,7 +12,7 @@ CPU_TUNE := strongarm
>>  
>>  KLIBCOPTFLAGS = -Os -march=$(CPU_ARCH) -mtune=$(CPU_TUNE)
>>  KLIBCBITSIZE  = 32
>> -KLIBCREQFLAGS = -fno-exceptions
>> +KLIBCREQFLAGS += -fno-exceptions
> 
> This should be fixed for KLIBCOPTFLAGS also. Unrelated to this issue.
> 

*Nod.*

	-hpa

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Miles Lane]

On 7/1/06, H. Peter Anvin <hpa@zytor.com> wrote:
> Sam Ravnborg wrote:
> >
> >> -KLIBCREQFLAGS     :=
> >> +KLIBCREQFLAGS     := $(call cc_option, -fno-stack-protector, )
> >
> > This needs to be $(call cc-option, ...)
> > '-' not '_'.
> >
>
> *plonk* OK... I feel dumb now :)
>
> Miles: could you try this out?
>
> >> +++ b/usr/klibc/arch/arm/MCONFIG
> >> @@ -12,7 +12,7 @@ CPU_TUNE := strongarm
> >>
> >>  KLIBCOPTFLAGS = -Os -march=$(CPU_ARCH) -mtune=$(CPU_TUNE)
> >>  KLIBCBITSIZE  = 32
> >> -KLIBCREQFLAGS = -fno-exceptions
> >> +KLIBCREQFLAGS += -fno-exceptions
> >
> > This should be fixed for KLIBCOPTFLAGS also. Unrelated to this issue.
> >
>
> *Nod.*

I gave it my best shot, but my build is still unhappy.
I set:
KLIBCREQFLAGS     :=  $(call cc-option, -fno-stack-protector, )
in scripts/Kbuild.klibc.

KLIBCOPTFLAGS     = -march=i386 -Os -g -fomit-frame-pointer
$(gcc_align_option) $(call cc-option, -fno-stack-protector, )
in usr/klibc/arch/i386/MCONFIG

CFLAGS          := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
                   $(call cc-option, -fno-stack-protector, ) -fno-common
in Makefile.

Trying to compile, I get:

include/asm/system.h: In function '__set_64bit_var':
include/asm/system.h:209: warning: dereferencing type-punned pointer
will break strict-aliasing rules

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[H. Peter Anvin]

Miles Lane wrote:
> 
> CFLAGS          := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
>                   $(call cc-option, -fno-stack-protector, ) -fno-common
> in Makefile.
> 
> Trying to compile, I get:
> 
> include/asm/system.h: In function '__set_64bit_var':
> include/asm/system.h:209: warning: dereferencing type-punned pointer
> will break strict-aliasing rules

That's because the kernel CFLAGS need to include -fno-strict-aliasing.

	-hpa

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Miles Lane]

On 7/1/06, H. Peter Anvin <hpa@zytor.com> wrote:
> Miles Lane wrote:
> >
> > CFLAGS          := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
> >                   $(call cc-option, -fno-stack-protector, ) -fno-common
> > in Makefile.
> >
> > Trying to compile, I get:
> >
> > include/asm/system.h: In function '__set_64bit_var':
> > include/asm/system.h:209: warning: dereferencing type-punned pointer
> > will break strict-aliasing rules
>
> That's because the kernel CFLAGS need to include -fno-strict-aliasing.

Okay, problem solved for me.  Can we get these patches in to the mm tree?

Thanks,
           Miles

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Arjan van de Ven]

> https://wiki.ubuntu.com/GccSsp
> 
> It appears that Ubuntu's Edgy Eft (the development tree) now contains
> "Stack Smashing Protection" enabled by default.  I found a web page
> that states that -fno-stack-protector can be used to disable this
> functionality.  Interestingly, another web page stated that SSP has
> been enabled in Redhat compilers for a long time and is now also
> enabled in Debian SID.  Perhaps -fno-stack-protector should be added
> to the kernel build be default?


gcc 4.1 and later have this feature yes.
HOWEVER the gcc people were not stupid, they did not force this on
people, they require you to put -fstack-protector on the commandline.
Debian and RH/Fedora do this.
If Ubuntu patched gcc rather than just putting it in the build
environment... then you should switch to a less braindead distribution
really ;)
or at least ask them to fix this.

Greetings,
   Arjan van de Ven

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Miles Lane]

On 7/2/06, Arjan van de Ven <arjan@infradead.org> wrote:
>
> > https://wiki.ubuntu.com/GccSsp
> >
> > It appears that Ubuntu's Edgy Eft (the development tree) now contains
> > "Stack Smashing Protection" enabled by default.  I found a web page
> > that states that -fno-stack-protector can be used to disable this
> > functionality.  Interestingly, another web page stated that SSP has
> > been enabled in Redhat compilers for a long time and is now also
> > enabled in Debian SID.  Perhaps -fno-stack-protector should be added
> > to the kernel build be default?
>
>
> gcc 4.1 and later have this feature yes.
> HOWEVER the gcc people were not stupid, they did not force this on
> people, they require you to put -fstack-protector on the commandline.
> Debian and RH/Fedora do this.
> If Ubuntu patched gcc rather than just putting it in the build
> environment... then you should switch to a less braindead distribution
> really ;)
> or at least ask them to fix this.

Well, from the web page referenced at the top of this message, you
can see that they are already aware of these issues:

Cons:
    *      It breaks current upstream kernel builds and potentially
other direct usages of gcc. Kernel is by far the most important use
case. Upstream should change the default options to build with
-fno-stack-protector by default.
    *      It is not conformant to upstream gcc behaviour.

You can reach the key people who are working on this for Ubuntu here:
Matt Zimmerman -- mdz at ubuntu dot com
Martin Pitt -- martin.pitt at ubuntu dot com

Perhaps you can convince them to back out this functional change?

Does this mean that you don't want to see these fno-stack-protector
patches go into Andrew's tree?

            Miles

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Arjan van de Ven]

> Does this mean that you don't want to see these fno-stack-protector
> patches go into Andrew's tree?

long term.. no. Because I want to enable stack-protector for the kernel
(I have patches for that; all it needs is a 5 line gcc patch to make it
work) as debug option at least (and if the perf impact isn't too bad,
distros and security sensitive people can enable it always). 

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[H. Peter Anvin]

Arjan van de Ven wrote:
> 
>> Does this mean that you don't want to see these fno-stack-protector
>> patches go into Andrew's tree?
> 
> long term.. no. Because I want to enable stack-protector for the kernel
> (I have patches for that; all it needs is a 5 line gcc patch to make it
> work) as debug option at least (and if the perf impact isn't too bad,
> distros and security sensitive people can enable it always). 
> 

Obviously, but at that time we should enable -fno-stack-protector vs 
-fstack-protector as appropriate.

	-hpa

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Arjan van de Ven]

On Sun, 2006-07-02 at 10:37 -0700, H. Peter Anvin wrote:
> Arjan van de Ven wrote:
> > 
> >> Does this mean that you don't want to see these fno-stack-protector
> >> patches go into Andrew's tree?
> > 
> > long term.. no. Because I want to enable stack-protector for the kernel
> > (I have patches for that; all it needs is a 5 line gcc patch to make it
> > work) as debug option at least (and if the perf impact isn't too bad,
> > distros and security sensitive people can enable it always). 
> > 
> 
> Obviously, but at that time we should enable -fno-stack-protector vs 

-fno-stack-protector doesn't even exist afaics; simply because gcc has
this as a positive commandline option only..

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Arjan van de Ven]

On Sun, 2006-07-02 at 19:50 +0200, Arjan van de Ven wrote:
> On Sun, 2006-07-02 at 10:37 -0700, H. Peter Anvin wrote:
> > Arjan van de Ven wrote:
> > > 
> > >> Does this mean that you don't want to see these fno-stack-protector
> > >> patches go into Andrew's tree?
> > > 
> > > long term.. no. Because I want to enable stack-protector for the kernel
> > > (I have patches for that; all it needs is a 5 line gcc patch to make it
> > > work) as debug option at least (and if the perf impact isn't too bad,
> > > distros and security sensitive people can enable it always). 
> > > 
> > 
> > Obviously, but at that time we should enable -fno-stack-protector vs 
> 
> -fno-stack-protector doesn't even exist afaics;

ok it does; I just tested on the wrong machine 
sorry

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[H. Peter Anvin]

Arjan van de Ven wrote:
>>>
>> Obviously, but at that time we should enable -fno-stack-protector vs 
> 
> -fno-stack-protector doesn't even exist afaics; simply because gcc has
> this as a positive commandline option only..

You actively have to fight gcc's internals to make a boolean option 
positive only, and that's a good thing.  The only reason it's possible 
at all are as a way to deal with multistate options.

	-hpa

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Ingo Molnar]

* Miles Lane <miles.lane@gmail.com> wrote:

> >If Ubuntu patched gcc rather than just putting it in the build
> >environment... then you should switch to a less braindead distribution
> >really ;)

> Well, from the web page referenced at the top of this message, you can 
> see that they are already aware of these issues:
> 
> Cons:
>    *      It breaks current upstream kernel builds and potentially
> other direct usages of gcc. Kernel is by far the most important use
> case. Upstream should change the default options to build with
> -fno-stack-protector by default.
>    *      It is not conformant to upstream gcc behaviour.

i think the only sane way for a generic distro to introduce an intrusive 
security feature is a 3-phase process:

 #1 - introduce the new security option
 #2 - increase use of it gradually, map all the exceptions on the way 
 #3 - once exceptions are mapped widely enough, switch the option to 
      default-on

this makes the introduction of security seemless/gradual to 
users/developers, without compromising on the end goal of having the 
security feature on by default.

Ubuntu seems to have opted to go to phase #3 directly, which is no doubt 
quite brutal but it's their choice. In any case, whichever methodology 
is used the kernel got flagged as an "exception" and we should help this 
security effort and change the kernel: i.e. lets apply the 
-fno-stack-protector flag to the kernel build.

	Ingo

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Miles Lane]

On 7/2/06, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Miles Lane <miles.lane@gmail.com> wrote:
>
> > >If Ubuntu patched gcc rather than just putting it in the build
> > >environment... then you should switch to a less braindead distribution
> > >really ;)
>
> > Well, from the web page referenced at the top of this message, you can
> > see that they are already aware of these issues:
> >
> > Cons:
> >    *      It breaks current upstream kernel builds and potentially
> > other direct usages of gcc. Kernel is by far the most important use
> > case. Upstream should change the default options to build with
> > -fno-stack-protector by default.
> >    *      It is not conformant to upstream gcc behaviour.
>
> i think the only sane way for a generic distro to introduce an intrusive
> security feature is a 3-phase process:
>
>  #1 - introduce the new security option
>  #2 - increase use of it gradually, map all the exceptions on the way
>  #3 - once exceptions are mapped widely enough, switch the option to
>       default-on
>
> this makes the introduction of security seemless/gradual to
> users/developers, without compromising on the end goal of having the
> security feature on by default.
>
> Ubuntu seems to have opted to go to phase #3 directly, which is no doubt
> quite brutal but it's their choice. In any case, whichever methodology
> is used the kernel got flagged as an "exception" and we should help this
> security effort and change the kernel: i.e. lets apply the
> -fno-stack-protector flag to the kernel build.

Well, I see that Andrew has accepted (mm5)
the -fno-stack-protector patch for the Makefile, but klibc remains
unpatched (scripts/Kbuild.klibc and usr/klibc/arch/i386/MCONFIG).
Would the right person in this dialog submit those changes to Andrew?

Many thanks,
        Miles

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[H. Peter Anvin]

Miles Lane wrote:
> 
> Well, I see that Andrew has accepted (mm5)
> the -fno-stack-protector patch for the Makefile, but klibc remains
> unpatched (scripts/Kbuild.klibc and usr/klibc/arch/i386/MCONFIG).
> Would the right person in this dialog submit those changes to Andrew?
> 

The fix is in my private tree, but given that we're in a merge window, I 
don't want to push it out right now until I've been able to figure out 
why an unrelated change cause make to spew warning messages.

	-hpa

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Robert Hancock]

Miles Lane wrote:
 > Trying to compile, I get:
 >
 > include/asm/system.h: In function '__set_64bit_var':
 > include/asm/system.h:209: warning: dereferencing type-punned pointer
 > will break strict-aliasing rules

Sounds like you're still getting a bunch of bad compile flags passed in. 
You likely need to remove the CFLAGS from your shell environment or 
something so that the kernel build stops inheriting them all.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Robert Hancock]

Miles Lane wrote:
> Well, from the web page referenced at the top of this message, you
> can see that they are already aware of these issues:
> 
> Cons:
>    *      It breaks current upstream kernel builds and potentially
> other direct usages of gcc. Kernel is by far the most important use
> case. Upstream should change the default options to build with
> -fno-stack-protector by default.
>    *      It is not conformant to upstream gcc behaviour.

I don't see why the kernel should have to insert compile flags to 
counteract any random non-default compile flags that the system may 
decide to insert. I think the way Ubuntu has done this is broken, they 
are essentially changing the default settings on the compiler in a way 
which breaks the kernel due to needing external libraries.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[H. Peter Anvin]

Robert Hancock wrote:
> Miles Lane wrote:
>> Well, from the web page referenced at the top of this message, you
>> can see that they are already aware of these issues:
>>
>> Cons:
>>    *      It breaks current upstream kernel builds and potentially
>> other direct usages of gcc. Kernel is by far the most important use
>> case. Upstream should change the default options to build with
>> -fno-stack-protector by default.
>>    *      It is not conformant to upstream gcc behaviour.
> 
> I don't see why the kernel should have to insert compile flags to 
> counteract any random non-default compile flags that the system may 
> decide to insert. I think the way Ubuntu has done this is broken, they 
> are essentially changing the default settings on the compiler in a way 
> which breaks the kernel due to needing external libraries.
> 

There is a good answer to that question, and that is, the kernel is the 
special case.  It DOES make sense to let the distribution set the 
default to whatever they think the end user should use for applications. 
  The kernel can deal with it easily enough.

	-hpa

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[Arjan van de Ven]

> There is a good answer to that question, and that is, the kernel is the 
> special case.  It DOES make sense to let the distribution set the 
> default to whatever they think the end user should use for applications. 

yeah.. but it's called "CFLAGS environment variable" :-)

Re: 2.6.17-mm5 -- Busted toolchain? -- usr/klibc/exec_l.c:59: undefined reference to `__stack_chk_fail'

[H. Peter Anvin]

Arjan van de Ven wrote:
>> There is a good answer to that question, and that is, the kernel is the 
>> special case.  It DOES make sense to let the distribution set the 
>> default to whatever they think the end user should use for applications. 
> 
> yeah.. but it's called "CFLAGS environment variable" :-)
> 

Absolutely not.  Setting a CFLAGS environment variable has an effect 
which is at very best unpredictable when dealing with a great span of 
applications.  Setting a CC environment variable is actually safer in 
many ways, but even that is cantankerous.

	-hpa