The new improved hardened gcc-4 specs management will no longer automatically disable the default-PIE behaviour when -nostdlib is specified (since '-nostdlib' says nothing about whether you're building ET_EXEC or ET_DYN executables; it was just a hack). This will cause grub to build badly. Specifically, it causes (amongst others) stage1.exec to be built -pie, which causes it to (on x86, for example) put most of the code at address 7c00, and other ELF stuff at 0x8048114. When this is converted to a binary file, you get a rather large file with acres of 0's. Obviously the grub stages shouldn't be built PIE since they're not loaded by linux (the upstream package already sets -fno-stack-protector, so no need to worry about SSP). It will just need: filter-flags -fPIE That will do its magic by modifying GCC_SPECS in the new scheme, so there's no need really to worry about CFLAGS, although doing it after the 'unset CFLAGS' doesn't hurt.
I'm not sure I happen to see not filtering pie or ssp when -nostdlib is passed as being a good thing. We for sure don't want to start adding custom hacks to kernels, bootloaders etc.
Well, IMO filtering based on -nostdlib is a lost cause, really, as it's a link-only flag; it kinda fixes some stuff (on some arches), but breaks others. Even here, you still get some PIC code in the stages which isn't ideal. Personally I think it is simpler and clearer if grub managed PIE explicitly. Incidentally, it turns out it breaks with SSP as well; grub does things like this: void grub_printf (const char *format,...) { int *dataptr = (int *) &format; char c, str[16]; dataptr++; expecting dataptr to now point to the second parameter. With gcc-4 ssp that's not the case - if it had used va_start/va_arg etc as normal it would have worked fine. Didn't trip on gcc-3 SSP because that wasn't sophisticated enough to instrument varargs functions (arguably one type of function at higher risk than most). Grub goes to some lengths to set -fno-stack-protector on a bunch of stuff, but it doesn't do it for libgrub_a compilations. Fix is to either add it also to libgrub_a, or more simply just to filter-flags it: filter-flags -fPIE -fstack-protector # bug #168834 BTW the filter on KERNEL is still present, since kernels are frequently built outside of portage.
yeah, i dont think -nostdlib should imply anything about PIE/PIC i also dont think there's any value in making grub work as PIC or PIE due to its nature (only root runs it, not setuid, it's a friggin bootloader, etc...) more to the point ... how does flag filtering help if -fPIE is in the specs ?
> more to the point ... how does flag filtering help if -fPIE is in the specs ? filter-flags is smart enough to realise that -fPIE is in the specs, and has to be inverted - the result the same as if -fPIE were in CFLAGS. Previously it would append '-fno-PIE' to CFLAGS; in the new scheme it appends "nopie.specs" colon-separated to GCCSPECS (nopie.specs being the minispec that sets the standard behaviour w.r.t. PIE). Similarly it appends "nossp.specs" when -fstack-protector filtering is requested. With GCC specs, it doesn't matter if the same spec is listed more than once - the last setting wins.
rather than relying on such magic mojo, wouldnt it be much more simple to simply append-flags -fno-PIE ?
The reason it is in filter-flags (and it's been like that for years now), was to make it more consistent with what an ebuild would do if the user had the flag in CFLAGS. The reason for doing the GCC_SPECS thing now rather than append to CFLAGS (which is what filter-flags previously did), is that it's more robust. Many packages that require the hardened stuff to be switched off again, are sensitive packages that often do not honour CFLAGS.
One other reason for using filter-flags was to provide a place where we can change how things are done (w.r.t. hardened) without having to get everyone to modify their ebuilds. I wouldn't be averse to providing an explicit interface (e.g. 'hardened-disable pie') rather than hiding it in filter-flags, if it's the hidden nature of the mojo that you don't like. In the end, 'append-flags -fno-PIE' will work if you honour CFLAGS, it's just different to what happens everywhere else.
listen to Kevin so ugly things like this don't happen. # ls -alh /lib/grub/i386-pc/ total 1.9G drwxr-xr-x 2 root root 4.0K Mar 7 13:44 . drwxr-xr-x 3 root root 4.0K Mar 7 13:40 .. -rw-r--r-- 1 root root 129M Mar 7 13:40 e2fs_stage1_5 -rw-r--r-- 1 root root 129M Mar 7 13:40 fat_stage1_5 -rw-r--r-- 1 root root 129M Mar 7 13:40 ffs_stage1_5 -rw-r--r-- 1 root root 129M Mar 7 13:40 iso9660_stage1_5 -rw-r--r-- 1 root root 129M Mar 7 13:40 jfs_stage1_5 -rw-r--r-- 1 root root 129M Mar 7 13:40 minix_stage1_5 -rw-r--r-- 1 root root 129M Mar 7 13:40 reiserfs_stage1_5 -rw-r--r-- 1 root root 129M Mar 7 13:40 stage1 -rw-r--r-- 1 root root 257M Mar 7 13:40 stage2 -rw-r--r-- 1 root root 257M Mar 7 13:40 stage2_eltorito -rw-r--r-- 1 root root 129M Mar 7 13:40 ufs2_stage1_5 -rw-r--r-- 1 root root 129M Mar 7 13:40 vstafs_stage1_5 -rw-r--r-- 1 root root 129M Mar 7 13:40 xfs_stage1_5
> # ls -alh /lib/grub/i386-pc/ > total 1.9G :) Nice, isn't it? Fortunately for most it's bad enough you usually notice when installing grub to the boot partition (if you have a handbook-style partitioning with a small boot partition there won't be enough space on it for those stage files and it'll fail to install). Also FEATURES=test will pick this up (grub's tests check the sizes of these files) and aborts the emerge. I'm on a kind of long-term personal crusade to get more people (devs especially, and hardened users) to set FEATURES=test by default :) BTW SpanKY isn't taking issue with whether or not to do anything; just debating how to do it.
added to cvs then
