OpenWrt Forum Archive

Topic: Correct way to use Stack Smashing Protection?

The content of this topic has been archived on 28 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

(moved from general discussion to this forum, which I think is more appropriate)

Compiling Attitude Adjustment branch from SVN r35608.
I have errors while compiling several packages after selecting CONFIG_SSP_SUPPORT=y
and
CONFIG_PACKAGE_libssp=y
in menuconfig.

Importantly for me, PACKAGE_fwknopd fails to compile (although off the top of my head, another example is PACKAGE_avahi-autoipd). The package compile failures issue the following message:

"Package fwknopd is missing dependencies for the following libraries:
libssp.so.0"

I note that there is a pre-compiled Attitude Adjustment 12.09 Beta package for fwknopd available for download, so what I am I doing wrong? How do you correctly compile with libssp -- especially those packages that require it?

Am I doing something wrong? Or is there a bug in a/some Makefile(s)? Why does it think I'm missing dependencies when libssp.so.0 is in my toolchain and also compiled as a rootfs package?

Proof:
phatgeek@localhost openwrt-aa-svn]$ find . | grep libssp.so.0
./staging_dir/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2/lib/libssp.so.0.0.0
./staging_dir/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2/lib/libssp.so.0
./staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/lib/libssp.so.0.0.0
./staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/lib/libssp.so.0
./build_dir/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2/gcc-linaro-4.6-2012.02-final/mips-openwrt-linux-uclibc/libssp/.libs/libssp.so.0.0.0
./build_dir/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2/gcc-linaro-4.6-2012.02-final/mips-openwrt-linux-uclibc/libssp/.libs/libssp.so.0
./build_dir/target-mips_r2_uClibc-0.9.33.2/toolchain/ipkg-ar71xx/libssp/lib/libssp.so.0.0.0
./build_dir/target-mips_r2_uClibc-0.9.33.2/toolchain/ipkg-ar71xx/libssp/lib/libssp.so.0
./build_dir/target-mips_r2_uClibc-0.9.33.2/OpenWrt-SDK-ar71xx-for-redhat-x86_64-gcc-4.6-linaro_uClibc-0.9.33.2/staging_dir/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2/lib/libssp.so.0.0.0
./build_dir/target-mips_r2_uClibc-0.9.33.2/OpenWrt-SDK-ar71xx-for-redhat-x86_64-gcc-4.6-linaro_uClibc-0.9.33.2/staging_dir/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2/lib/libssp.so.0
./build_dir/target-mips_r2_uClibc-0.9.33.2/OpenWrt-SDK-ar71xx-for-redhat-x86_64-gcc-4.6-linaro_uClibc-0.9.33.2/staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/lib/libssp.so.0.0.0
./build_dir/target-mips_r2_uClibc-0.9.33.2/OpenWrt-SDK-ar71xx-for-redhat-x86_64-gcc-4.6-linaro_uClibc-0.9.33.2/staging_dir/target-mips_r2_uClibc-0.9.33.2/root-ar71xx/lib/libssp.so.0
./build_dir/target-mips_r2_uClibc-0.9.33.2/OpenWrt-Toolchain-ar71xx-for-mips_r2-gcc-4.6-linaro_uClibc-0.9.33.2/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2/lib/libssp.so.0.0.0
./build_dir/target-mips_r2_uClibc-0.9.33.2/OpenWrt-Toolchain-ar71xx-for-mips_r2-gcc-4.6-linaro_uClibc-0.9.33.2/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2/lib/libssp.so.0

Thanks,
Phat

An update, for posterity:
I manually added +libssp to the DEPENDS: sections in the fwknop and avahi Makefiles. Afterwards, these packages compiled fine. I may have overdone the DEPENDS additions, as I added it to the DEPENDS variable in every name space in the Makefiles. I'll do some experimenting, especially for avahi, since there are many different packages defined...

I'll submit a bug report and a patch in the near future. The way I compiled it was a hack, and I want to figure out the correct way first, then generate patches to fix the bugs. Looks like it's maybe just the two package makefiles, avahi and fwknop. I didn't have any other issues when I compiled (but I didn't try to compile all packages, either).

I saw in one of the Makefiles a syntax that looks like:
"+SSP_SUPPORT:libssp"

Am I correct in assuming this means, "if SSP_SUPPORT, then add libssp to the DEPENDS variable"? And is the syntax correct?
Phat

The discussion might have continued from here.