A little background: This is a new gentoo system that's pretty up to date (portage and stuff up to date from this) (it's an nptl system with linux26-headers, works fine). I recently installed hardened-dev-sources, they work fine without any of the extra options enabled.. What I just did before this was 1) enable Pax in kernel as per the quickstart guide on h.g.o 2) added USE=hardened to make.conf 3) emerge paxctl paxutils, etc... 4) emerge binutils gcc glibc && emerge -e world .. and apparently it stopped in emerge -e world on grub checking for i686-pc-linux-gnu-gcc option to accept ANSI C... none needed checking for style of include used by make... GNU checking dependency style of i686-pc-linux-gnu-gcc... gcc3 checking dependency style of i686-pc-linux-gnu-gcc... (cached) gcc3 checking for i686-pc-linux-gnu-ranlib... no checking for ranlib... ranlib checking whether optimization for size works... yes checking whether -Wundef works... yes checking whether -falign-loops works... yes checking for i686-pc-linux-gnu-objcopy... no checking for objcopy... objcopy checking if C symbols get an underscore after compilation... no checking whether objcopy works for absolute addresses... configure: error: i686-pc-linux-gnu-gcc cannot link at address 2000 !!! Please attach the config.log to your bug report: !!! /var/tmp/portage/grub-0.94-r1/work/grub-0.94/config.log !!! ERROR: sys-boot/grub-0.94-r1 failed. !!! Function econf, Line 485, Exitcode 0 !!! econf failed Reproducible: Always Steps to Reproduce: 1. 2. 3. Portage 2.0.51-r14 (default-linux/x86/2004.3, gcc-3.3.5, glibc-2.3.4.20040808- r1, 2.6.10-hardened-r3 i686) ================================================================= System uname: 2.6.10-hardened-r3 i686 Intel(R) Pentium(R) 4 CPU 2.00GHz Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Jan 26 2005, 11:30:55)] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.59-r5 sys-devel/automake: 1.8.5-r1 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.2-r7 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share /config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig distlocks sandbox sfperms" GENTOO_MIRRORS="ftp://gentoo.chem.wisc.edu/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 apache2 berkdb crypt curl doc fam hardened ldap libclamav maildir mailwrapper mmx nptl nptl-only pam pcre perl php postgres python readline samba sasl sse ssl tcpd unicode vhosts zlib" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS
Created attachment 49668 [details] config.log Here's the config.log requested
Some thoughts.. It looks to me like it could be something to do with glibc or gcc built with +hardened. Perhpaps glibc also needs +pic as noted in use.local.desc? This would also warrant a documentation update for the PaX quickstart guide... I'll give +pic a try
+pic doesn't help, switching to hardened/x86 profile doesn't help
Here's the ouput of gcc -v: Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/specs Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/hardenednopie.specs Configured with: /var/tmp/portage/gcc-3.3.5-r1/work/gcc-3.3.5/configure --enable-version-specific-runtime-libs --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3.5 --includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3.5/info --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.5/include/g++-v3 --host=i686-pc-linux-gnu --disable-altivec --disable-nls --enable-__cxa_atexit --enable-clocale=gnu --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --enable-shared --enable-threads=posix --disable-multilib --disable-libgcj --enable-languages=c,c++ Thread model: posix gcc version 3.3.5 (Gentoo Hardened Linux 3.3.5-r1, ssp-3.3.2-3, pie-8.7.7.1) Here's output from gcc-config -l: [1] i686-pc-linux-gnu-3.3.5 * [2] i686-pc-linux-gnu-3.3.5-hardenednopie [3] i686-pc-linux-gnu-3.3.5-hardenednossp [4] i686-pc-linux-gnu-3.3.5-vanilla (I'm using the hardened-profile, so i'm assuming that means it's the -hardened version) also set | grep GCC: GCC_SPECS= (that must be normal for the hardened profile too) Let me know before 4:00 EST if you need more info
Seems to be compiler-version-specific. Builds fine with gcc-3.4.3 (hardened).
Created attachment 49785 [details, diff] Make netboot build conditional on use netboot; fix flag management This fixes the 0.94-r1 ebuild I think. Note however that netboot won't build.
Created attachment 49786 [details, diff] Same but for 0.94-r2
Created attachment 49787 [details, diff] same but for 0.95 ebuild
.94-r2 emerges fine on my non-hardened system using the regular gcc spec
Created attachment 49823 [details, diff] Updated patch for 0.94-r1 Changed to remove use of has_pie/has_ssp, as they're redundant with test_flag. Logic now looks the same as that in the lilo builds. Fixed QA issue on netboot use flag.
Created attachment 49824 [details, diff] Updated patch for 0.94-r2 Change description same as -r1
Created attachment 49825 [details, diff] Updated patch for 0.95... As above (netboot was already conditional in this version)
Created attachment 50051 [details] Patch Failure grub-0.94-r1 on hardened x86 here, the patch posted above for that ebuild does not work here. In fact, it fails to patch the ebuild correctly - .rej file attached. I get this when I proceed to emerge - emerge --oneshot --nodeps grub Calculating dependencies ...done! >>> emerge (1 of 1) sys-boot/grub-0.94-r1 to / >>> md5 src_uri ;-) grub-0.94.tar.gz >>> md5 src_uri ;-) grub-0.94-splash.patch.bz2 >>> Unpacking source... >>> Unpacking grub-0.94.tar.gz to /var/tmp/portage/grub-0.94-r1/work >>> Unpacking grub-0.94-splash.patch.bz2 to /var/tmp/portage/grub-0.94-r1/work * Applying grub-0.94-splash.patch ... [ ok ] * Applying grub-0.94-gcc3.4.patch ... [ ok ]>>> Source unpacked. /usr/lib/portage/bin/ebuild.sh: line 1: -fno-pic: command not found At which point it proceeds to configure as normal, then fails with the "cannot link at address 2000" error.
Created attachment 50054 [details, diff] Updated patch for 0.94-r1 Don't know what went wrong with that patch, sorry - this one works.
Created attachment 50057 [details, diff] Updated patch for 0.94-r2
Created attachment 50058 [details, diff] Updated patch for 0.95...
Updated patch for 0.94-r1 works OK here.
I just ran into this problem too ... and the updated patch for 0.94-r1 fixed it for me as well.
Created attachment 50222 [details, diff] Updated patch for 0.95... Ignore the previous 0.95 one, that was garbage
Kevin. Please. Take a look. May be that ebuild should be fixed also. http://bugs.gentoo.org/show_bug.cgi?id=80693
Created attachment 50837 [details, diff] Updated patch for 0.94-r1
something changed in the 0.94-r1 ebuild ... the patch failed on another system that I was converting to hardened. I submitted an updated patch (I haven't looked at 0.94-r2 and 0.95).
I have patches hanging out in my ~ which come from psm which allow grub to be compiled PIC. Our grub has to many Q/A problems so I don't want to commit these fixes. I've mailed robmoss but he appears to be MIA. http://dev.gentoo.org/~solar/grub-0.94-textrel.patch http://dev.gentoo.org/~solar/grub-ebuild.diff
since Rob is AWOL i'm putting together an 0.96 ebuild that so far solves many of the bugs mentioned in #80693. concerning this particular issue, which solution would you rather i implement at this time - kevin's ebuild patch or solar's textrel patch? thanks.
Ultimately, fixing textrel/PIC properly is preferable, however eyeballing psm/solar's patches it may be they only work on some systems. It looked to me that cleaning up the ebuild to start with would resolve a lot of the open bugs. My patch isn't ideal; I took the path-of-least-resistance approach, changing as little as possible as I wasn't sure what parts of the ebuild were necessary and which were just cruft. I suggest vigorously cleaning up the ebuild, add psm/solar's patches suitably tweaked to fit rather than mine, but post here first so people here can comment and test it.
the patches are psm.. Adding him to the CC: so he knows whats going on.
request for testers on bug #80693. i tried to clean up as many bugs as i could manage, but some are over my head. i don't have a hardened system so i can't verify the PIC patch works, but it does build nicely for me. ;] it still needs to be scrubbed down by someone with more experience writing ebuilds than i, so feel free to tear it apart at will.
1) This: BLOCK_BACKUP="$BLOCK_SIZE" unset BLOCK_SIZE in global scope with this: export BLOCKSIZE="$BLOCK_BACKUP" at the end seems a bit odd. Perhaps an ebuild expert could comment, but it looks to me like it ought to be in src_compile() and perhaps a src_test() function. 2) On hardened, the netboot stuff fails - at this point due to non-PIC asm in netboot/main.c, and probably in netboot/pci.c (both of which clobber BREG). It'll take an asm patch to fix it, which I can do, but it'll take a little time. I would suggest worrying about that later though; no-one has bugged before about netboot on hardened, so perhaps no-one that uses hardened uses netboot yet. 3) I also got: /usr/lib/portage/bin/ebuild.sh: line 1858: 19306 Killed /sbin/grub --batch --device-map=/boot/grub/device.map </boot/grub/grub.conf >/dev/null 2>&1 reported during the merge phase. For some reason /sbin/grub has 'E' in its pax flags; changing the paxctl/chpax lines to '-spme' to allow emulation of trampolines stops it being killed. Also, I think paxctl should be tried first before chpax, as paxctl settings are used by kernels that have both types of flags configured in preference to chpax flags. 4) I'm not sure what running /sbin/grub like it is in the ebuild is supposed to achieve. Installing the boot sector needs different commands than exist in a live grub.conf, and is probably something best left to the user as it's easy to hose the system. Perhaps this should be removed? 5) On style, I think it's preferred to use '[[' rather than '['; this is simple to change, apart from swapping [ for [[ and ] for ]], just line 134 needs '&&' instead of '-a'. Also a number of lines start with spaces instead of tabs; if you're a vi user and have gentoo-syntax emerged, vi will show these highlighted.
Sorry - posted to wrong bug - should have been to bug #80693 (reposted there)
the E flag is "normal" for grub, because it is full of nested functions that were used on purpose (grep for nested in src too see comments), and the nested function triggers E (and also the execstack marking). -spme is ok, works for me (although for normal users the trampolines shouldn't be enabled in the kernel, so E/e shouldn't make any difference)
*** Bug 80144 has been marked as a duplicate of this bug. ***
0.96-r1 should be ok
*** Bug 89085 has been marked as a duplicate of this bug. ***
the fix is in ~arch grub right now. when that goes stable this bug should slow down.
Confirming fixed. Build and boot with grub-0.96-r1 (which just went stable) works for me under hardened now (the missing digest problem described in bug #89847 notwithstanding - I digested it manually).
this bug still exists for hardened systems trying to use netboot - someone suggested in these comments it wans't an issue because no one has bugged about it... well... that's no longer the case :) can this be reoppened? Bug 97146 is also about this, and was closed as invalid I am using sys-kernel/linux-headers-2.6.11-r2 as suggested pci.c: In function `bios32_service': pci.c:107: error: can't find a register in class `BREG' while reloading `asm' make[2]: *** [libdrivers_a-pci.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/grub-0.96-r2/work/grub-0.96/netboot' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/grub-0.96-r2/work/grub-0.96' make: *** [all] Error 2
Rebuilt grub last night in fact. tinderbox # emerge -qpv grub|grep ebuild [ebuild R ] sys-boot/grub-0.96-r2 -custom-cflags -netboot -static 1,042 kB tinderbox # emerge -V Portage 2.0.54 (hardened/x86/2.6, gcc-3.4.4, glibc-2.3.5-r2, 2.6.11-hardened-r15 i686) tinderbox # emerge -pv linux-headers|grep ebuild [ebuild R ] sys-kernel/linux-headers-2.6.11-r2 36,470 kB Not sure what problem your having but current stable builds grub just fine.
set the netboot flag and try again - you'll see it fail.. atleast, I do.
Created attachment 77945 [details, diff] pic-ifies the netboot code. The problem arises when built with USE=netboot. I don't know if we want to worry about this much; reworking the netboot code is probably risky and of little benefit. However here's a patch against 0.96-r2 that builds - however use completely at your own risk, I make no guarantees as I can't test netboot.
reopening for netboot
still not quite there I'm afraid.... should this be reported upstream? Thanks for all your efforts - much appreciated! Calculating dependencies ...done! [ebuild R ] sys-boot/grub-0.96-r2 -custom-cflags +netboot* -static 0 kB [2] * 070_all_grub-0.96-gcc2.patch ... [OK] * Done with patching * Applying netboot.patch ... [OK] pci.c: In function `pcibios_read_config_byte': pci.c:146: error: can't find a register in class `BREG' while reloading `asm' make[2]: *** [libdrivers_a-pci.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/grub-0.96-r2/work/grub-0.96/netboot' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/grub-0.96-r2/work/grub-0.96'
whoops - did the patch, forgot to do USE=netboot :) There's a pile of asm bits that clobber bx; I'm leaning towards suggesting: CFLAGS="-nopie" emerge grub or "use netboot && filter-flags -fPIE" in the ebuild. Going upstream on 0.9x is probably a waste of time - the 0.9x series is effectively a dead branch development-wise. The new "grub 2" (see 1.92 in portage) is a completely new beast really, with the same name. I'm not sure if 1.92 supports network booting or not, but it looks like it doesn't have any PIC problems.
Comment on attachment 77945 [details, diff] pic-ifies the netboot code. patch is rubbish (well, significantly incomplete!)
well.. a different errror, I think we're making progress - thanks for sticking with me on this one :) firstly, grub filters cflags without the custom-cflags option, so I set this flag, and chnaged CFLAGS in make.conf to be empty. # CFLAGS="-nopie" emerge grub -av results in a *lot* of errors, here's a sample... w89c840.c:(.text+0xa98): undefined reference to `__guard' w89c840.c:(.text+0xb72): undefined reference to `__guard' w89c840.c:(.text+0xb87): undefined reference to `__stack_smash_handler' ../netboot/libdrivers.a(libdrivers_a-timer.o): In function `load_timer2': timer.c:(.text+0x7): undefined reference to `__guard' timer.c:(.text+0x16): undefined reference to `__inbc' timer.c:(.text+0x2d): undefined reference to `__outbc' timer.c:(.text+0x41): undefined reference to `__outbc' timer.c:(.text+0x55): undefined reference to `__outbc' timer.c:(.text+0x6e): undefined reference to `__outbc' timer.c:(.text+0x77): undefined reference to `__guard' timer.c:(.text+0x8c): undefined reference to `__stack_smash_handler' this seems to me to be hardened ralated with names like __guard and __stack_smash_handler, but I thougth our cflag should have been disabling this? Ian
there is another bug about this, CFLAGS is not allowed to be defined when running configure
I can't find the other bug, do you know what number it is?
80693/c60
(In reply to comment #36) > pci.c:107: error: can't find a register in class `BREG' while reloading `asm' Bug 139277 - either mark it as duplicate of this one or preferably close this one and move there, it hasn't got anything in common with the original issue here (which has been fixed).
old issue
