On 5/29/10, Bruce Dubbs <bruce.dubbs at gmail.com> wrote:
> $ nm -a /mnt/lfs/tools/lib/libssp.so.0.0.0|grep stack
> 0000000000001000 T __stack_chk_fail
> 0000000000001040 t __stack_chk_fail_local
> 0000000000201d60 B __stack_chk_guard
>
nm -a /usr/lib/libssp.so.0.0.0 | grep stack
shows similar output on backups with linux-2.6.18.8 similar as 2.6.33, e.g.,:
00000c10 T __stack_chk_fail
00000c50 t __stack_chk_fail_local
000025a8 B __stack_chk_guard
http://cateee.net/lkddb/web-lkddb/CC_STACKPROTECTOR.html
arch/x86/Kconfig
The configuration item CONFIG_CC_STACKPROTECTOR:
* prompt: Enable -fstack-protector buffer overflow detection (EXPERIMENTAL)
* type: tristate
* depends on: CONFIG_X86_64 && CONFIG_EXPERIMENTAL && CONFIG_BROKEN
* defined in arch/x86/Kconfig
* found in Linux Kernels: from 2.6.19 release still available on
2.6.34 release
Help text
This option turns on the -fstack-protector GCC feature. This feature
puts, at the beginning of critical functions, a canary value on the
stack just before the return address, and validates the value just
before actually returning. Stack based buffer overflows (that need to
overwrite this return address) now also overwrite the canary, which
gets detected and the attack is then neutralized via a kernel panic.
This feature requires gcc version 4.2 or above, or a distribution gcc
with the feature backported. Older versions are automatically detected
and for those versions, this configuration option is ignored.
hrmm
# CONFIG_CC_STACKPROTECTOR is not set
is not seen in any /boot/config-x.y.z (kernel config) files I have
saved until gcc became >= 4.2
"Older versions are automatically detected and for those versions,
this configuration option is ignored."
[ ... thinking ...] thus would not be a possible kernel config option.
I guess
this is something different from libssp
Can you not go across the gcc 4.2 boundary to or from a 2.6.18 kernel?
What if you built a Linux-2.6.22.5 kernel on the host and try that?