Re: [PATCHSET x86/master] add stack protector support for x86_32




* Tejun Heo <tj@xxxxxxxxxx> wrote:

Ingo Molnar wrote:
I'll try other compilers but which version are you using? The
difference is that before the patchset, -fno-stack-protector was
always added whether stackprotector was enabled or not so this problem
wasn't visible (at the cost of bogus stackprotector of course). We'll
probably need to add __stack_chk_guard or disable if gcc generates
such symbol. I'll play with different gccs.
Can't reproduce with gcc-4.1 or 4.2. Any chance you're using distcc
w/ a build machine w/ glibc < 2.4? __stack_chk_guard is the symbol
gcc fetches stack canary from if TLS is not supported, so somehow gcc
thought that TLS wasn't available while building head64.

yeah - i also used distcc. Maybe the nostackp makefile magic gets confused
about that?

It seems that even with the same gcc versions, gcc built against libc
w/o TLS support generates __stack_chk_guard, so if you mix the two
flavors, the has-stack-protector check can be compiled on machines w/
TLS while some other files end up being built on machines w/o TLS
support thus circumventing the support check. Can you please see
whether non-distcc build fails too?

That build succeeds:

rhea:~/tip> make -j30 bzImage ARCH=x86_64 CROSS_COMPILE='/opt/crosstool/gcc-4.2.3-glibc-2.3.6/x86_64-unknown-linux-gnu/bin/x86_64-unknown-linux-gnu-'
/home/mingo/tip/arch/x86/Makefile:82: stack protector enabled but no compiler support
CHK include/linux/version.h
[...]
BFD: arch/x86/boot/compressed/vmlinux.bin: warning: allocated section `.bss' not in segment
[...]
Root device is (8, 3)
Setup is 11996 bytes (padded to 12288 bytes).
System is 5690 kB
CRC be1b2e21
Kernel: arch/x86/boot/bzImage is ready (#3)

Some shell variable expansion bug? If CROSS_COMPILE is not a single word
we fail to detect the compiler borkage at arch/x86/Makefile line 82?

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Re: [PATCH] stackprotector: fix multi-word cross-builds
    ... wasn't visible (at the cost of bogus stackprotector of course). ... gcc fetches stack canary from if TLS is not supported, ... thought that TLS wasn't available while building head64. ... support thus circumventing the support check. ...
    (Linux-Kernel)
  • Re: [PATCHSET x86/master] add stack protector support for x86_32
    ... wasn't visible (at the cost of bogus stackprotector of course). ... gcc fetches stack canary from if TLS is not supported, ... thought that TLS wasn't available while building head64. ... support thus circumventing the support check. ...
    (Linux-Kernel)
  • [PATCH] stackprotector: fix multi-word cross-builds
    ... wasn't visible (at the cost of bogus stackprotector of course). ... gcc fetches stack canary from if TLS is not supported, ... thought that TLS wasn't available while building head64. ... support thus circumventing the support check. ...
    (Linux-Kernel)
  • Re: sudo and UNIXes (was: audacity export wma format[1 more question])
    ... You mean the first thing you compile on a new system isn't gcc? ... On Solaris I use vendor packages with gcc, ... are companies that have full paid support for RHEL. ...
    (Debian-User)
  • Re: math.nroot [was Re: A brief question.]
    ... > so before VC 7.1 was released (C99 ain't exactly new anymore). ... > support _some_ way to get at this stuff. ... This includes gcc before C99 ... > and fenv.h -- if the platforms represented in fpectlmodule.c were ...
    (comp.lang.python)