I'm using the gcc 4.4.2-r2 from the hardened-dev overlay and recently tried to compile a kernel with the fstack-protector switch enabled
(menuconfig->processor type and features->stack-protector).
When building the kernel, the make-script complains with a message that there is no compiler-suppert ("stack protector enabled but no compiler support") which obviously is not true. I think it then discards the flag (not sure about that).
I looked into it. The kernel build system has a script which checks whether the kernel has support for fstack-protector or not (scripts/gcc-x86_64-has-stack-protector.sh)
On a non-hardened gcc-4.3.4 these scripts work well. But on gentoo-hardened gcc 4.4.2 the compiler throws an error (error: code model kernel does not support PIC mode). I think this is caused by the hardened profile. To fix this, the -fno-pic flag has to be added in the call to gcc in the scripts.
The fixed script is attached.
Steps to Reproduce:
1. install gcc-4.4.2-r2 from hardened-dev overlay
2. install hardened-sources-2.6.32-r5 from hardened-dev overlay
3. enable CONFIG_CC_STACKPROTECTOR=y in kernel config
the kernel should build with fstack-protector enabled
the build system complains about missing compiler support
Portage 184.108.40.206 (hardened/linux/amd64/10.0, gcc-4.4.2, glibc-2.10.1-r1, 2.6.28-hardened-r9 x86_64)
System uname: Linux-2.6.28-hardened-r9-x86_64-Intel-R-_Atom-TM-_CPU_330_@_1.60GHz-with-gentoo-1.12.13
Timestamp of tree: Tue, 30 Mar 2010 04:00:01 +0000
sys-devel/automake: 1.9.6-r3, 1.10.3
sys-devel/gcc: 4.3.4, 4.4.2-r2
CFLAGS="-O2 -pipe -march=core2"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe -march=core2"
FEATURES="assume-digests distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch"
GENTOO_MIRRORS="http://de-mirror.org/distro/gentoo/ http://gentoo.mneisen.org/ http://gentoo.tiscali.nl/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
USE="acl alsa amd64 bash-completion berkdb bzip2 cli cracklib crypt cups cxx dri gdbm gpm hardened iconv jpeg jpeg2k justify mmx modules mp3 mudflap multilib ncurses nls nptl nptlonly ogg openmp pam pcre perl pic png pppd python readline reflection session spl sse sse2 ssh ssl svg sysfs tcpd threads tiff tls unicode urandom utf8 vhosts vorbis xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga neomagic nv r128 radeon savage sis tdfx trident vesa via vmware voodoo"
Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 225913 [details, diff]
fix for scripts/gcc-x86_64-has-stack-protector.sh
It should be noted, that there also is a
scripts/gcc-x86_32-has-stack-protector.sh check-script. I haven't tried/tested/fixed it, but I guess the same bug will occur there, too.
Created attachment 225963 [details, diff]
Fix the KERNEL SSP check with hardened toolchain
Test this patch
It add CPPFLAGS to the commandline for the SSP test.
We use CPPFLAGS (-D__KERNEL__) to disabla hardened SSP/PIE as default.
Yes, your Makefile-patch works as well.
Zorry please leave bugs assigned to hardened alias so everyone in the group can track the bug.
(In reply to comment #5)
> Zorry please leave bugs assigned to hardened alias so everyone in the group can
> track the bug.
No, this is clearly hardened-kernel@ issue. Add yourself to the hardened-kernel@ alias if you want. CC'd you for now.
(In reply to comment #6)
> No, this is clearly hardened-kernel@ issue.
Could you explain the rationale behind this statement? Using a Gentoo hardened gcc 4.4.4-r1 to build a non-hardened 220.127.116.11 kernel exhibits the same problem. Both of the proposed patches result in correct behavior of the kernel test program and apply cleanly to non-hardened sources. It seems like the greatest benefit would be to push the change from attachment #225963 [details, diff] upstream so that the test program is consistent in its specification of kernel versus user. At present, it passes -mcmodel=kernel, but then omits -D__KERNEL__, which seems to be the traditional CPP define used for kernel code.
(In reply to comment #7)
> (In reply to comment #6)
> > No, this is clearly hardened-kernel@ issue.
> Could you explain the rationale behind this statement? Using a Gentoo hardened
> gcc 4.4.4-r1 to build a non-hardened 18.104.22.168 kernel exhibits the same problem.
> Both of the proposed patches result in correct behavior of the kernel test
Its actually a kernel@ issue since the patch to fix it needs to go upstream to the kernel maintainers. I've tried, but the patch was intercepted by one of the email list fiters (I think) and never even made it to lkml. I'm cc-ing email@example.com. Maybe they can help in getting it accepted. Otherwise, I will start to include the patch in the hardened-sources patchset.
*** Bug 330069 has been marked as a duplicate of this bug. ***
(In reply to comment #8)
> Its actually a kernel@ issue since the patch to fix it needs to go upstream to
> the kernel maintainers. I've tried, but the patch was intercepted by one of
> the email list fiters (I think) and never even made it to lkml. I'm cc-ing
> firstname.lastname@example.org. Maybe they can help in getting it accepted.
To avoid it getting lost in mailing lists, I reported this upstream at <https://bugzilla.kernel.org/show_bug.cgi?id=17852>.
hardened-source-2.6.34-r2 has the same issue. could the patch be supplied with the ebuild?
(In reply to comment #11)
> hardened-source-2.6.34-r2 has the same issue. could the patch be supplied with
> the ebuild?
I will wait a little longer to see if there's any progress on the bug upstream and if not, start including it.
(In reply to comment #12)
> (In reply to comment #11)
> > hardened-source-2.6.34-r2 has the same issue. could the patch be supplied with
> > the ebuild?
> I will wait a little longer to see if there's any progress on the bug upstream
> and if not, start including it.
I resubmitted the patch as per the upstream bug request and this time it made it through to lkms. I'm still including the patch in the next releases because who knows how long before it gets incorporated.
Okay good news and good news:
1) The patch was accepted. Thanks Kai and Zorry :)
2) Since it will be a while until it trickles back down to us, the patch is in hardened-sources-2.6.32-r17 and hardened-sources-2.6.34-r5 which just hit the tree.
I'm going to close this one. Please anyone, feel free to reopen if there's any problem or issue that further needs addressing.
*** Bug 336625 has been marked as a duplicate of this bug. ***