dev-lang/ghc-6.10.4-r1 does not alter ghc-wrapper provided by USE="binary" This is creates at least two problems on hardened: Problem 1: # USE="binary" emerge ghc This on hardened installs ghc. but since it does not add "-optc-nopie -optl-nopie" to /usr/bin/ghc you still cannot compile anything unless you do it yourself. Problem 2: # USE="-binary" emerge ghc Since ghc still uses the same ghc-wrapper as USE="binary" but now for compiling ghc the compilation of ghc fails for the same reason. Solution: for hardened users add -optc-nopie and -optl-nopie to ghc-wrapper from the binary tarball before trying to compile/install anything.
Since ivanm commented on IRC that he did not understand some parts of this bug I will comment on some background and other things: Hardened compiles as much as it can as PIE. Now for different reasons haskell (or at least ghc) fails to link files compiled as PIE. Hardened toolchain has implemented a flag called "-nopie" that should be used in these cases, and since ghc uses gcc for linking we can let ghc-wrapper pass this option to gcc and everything is fine again. The ebuild should already do this for USE="-binary" in ${S}/ghc/ghc.wrapper with the following parts of the ebuild: ghc-6.10.4-r1.ebuild lines 127: gcc-specs-pie && append-ghc-cflags compile link -nopie and ghc-6.10.4-r1.ebuild lines 179: # Modify the ghc driver script to use GHC_CFLAGS sed -i -e "s|wrapped|wrapped ${GHC_CFLAGS}|" \ "${S}/ghc/ghc.wrapper" Now the problem is that while building ghc by default it does the following: ghc-6.10.4-r1.ebuild lines 164: sed -i -e "s|/usr|${WORKDIR}/usr|g" \ "${WORKDIR}/usr/bin/ghc-${PV}" \ "${WORKDIR}/usr/bin/ghci-${PV}" \ "${WORKDIR}/usr/bin/ghc-pkg-${PV}" \ "${WORKDIR}/usr/bin/hsc2hs" \ "${WORKDIR}/usr/$(get_libdir)/${P}/package.conf" \ || die "Relocating ghc from /usr to workdir failed" which means that while building ghc you do not use the wrapper you changed but the wrapper you untared from the already built ghc. This makes ghc try to build itself without "-optc-nopie -optl-nopie" which fails in linking. Now when it comes to USE="binary" it does not even try to change any wrapper, which merges ghc fine, but fails to link anything other you compile with ghc. So yes, this is a bug. and one kind of fix (tested only with USE="binary") could be to just after ghc_setup_cflags in src_unpack add something like: sed -i -e "s|wrapped|wrapped ${GHC_CFLAGS}|" \ "${WORKDIR}/usr/bin/ghc-${PV}"
Hmmm.... that almost makes sense. I'm not in front of my Gentoo box at the moment, and thus can't check this, but the fix for USE="-binary" might be to patch the wrapper script before using it to build. Since I'm not familiar with hardened: is there any reason not to have -nopie in the wrapper script always?
(In reply to comment #2) > Since I'm not familiar with hardened: is there any reason not to have -nopie in > the wrapper script always? > Well, AFAICS there should be no harm in that, but zorry is really the one who can answer that.
@zorry, is there any cases where gcc can break if you pass -nopie to it? If there is not, then I think it can be a good idea to always pass -nopie.
(In reply to comment #4) > @zorry, is there any cases where gcc can break if you pass -nopie to it? > > If there is not, then I think it can be a good idea to always pass -nopie. > The prob is that the -nopie is not a supported flag for default gcc You will get a warning or i will fail.
(In reply to comment #1) > and one kind of fix (tested only with USE="binary") could be to just after > ghc_setup_cflags in src_unpack add something like: > > sed -i -e "s|wrapped|wrapped ${GHC_CFLAGS}|" \ > "${WORKDIR}/usr/bin/ghc-${PV}" > I think this should work. Can anyone test this with USE="-binary" ?
It fixes USE="binary" here. For USE="-binary" on hardened the situation is a little bit more complicated. Now it passes configure, but it fails later on during boot.stage.1, apparently because something does not use the wrapper for compilation (an does not pass -nopie to gcc). Now I feel that if this also works with a vanilla toolchain, then lets apply it and close this bug. Other hardened breakage is for other bugreports. But with this at least you can get a working ghc by using USE="binary".
So, happy people, how about we do the proposed change, so we have a working ghc in hardened (i.e. USE="binary" emerge haskell) and leave the rest of the hardened problems for another bugreport? Maybe as as a revision so if it start to breaks for vanilla people for strange reasons, then we will catch that? The proposed change was --- /var/portage/dev-lang/ghc/ghc-6.10.4-r1.ebuild 2010-03-31 04:36:03.000000000 +0200 +++ ghc-6.10.4-r2.ebuild 2010-05-03 18:23:26.990527598 +0200 @@ -155,6 +155,10 @@ base_src_unpack ghc_setup_cflags + # Modify the wrapper script from the binary tarball to use GHC_CFLAGS + sed -i -e "s|wrapped|wrapped ${GHC_CFLAGS}|" \ + "${WORKDIR}/usr/bin/ghc-${PV}" + if use binary; then # Move unpacked files to the expected place
Created attachment 230981 [details, diff] Patch for ebuild This patch makes ghc-6.10.4 compile and run on Gentoo hardened
Created attachment 230983 [details, diff] Patch against ghc-6.12.1 ebuild This patch makes ghc 6.12.1 compile and run in gentoo hardened. The patches contains two changes: The first is removing filter-flags for -fPIC since it is totally unnessecary and only breaks compilation. filter-flags does in the build only change what is passed to gcc. This breaks since -nopie is never passed while linking. This does not break ghc because the only part that actually does not work with PIE/PIC is ghc itself, and it is taken care of by the other change. The second change is just sed'ing in the same changes into the binary ghc wrapper as you already sed into the wrapper which will get installed. This since the first wrapper is actually the one building ghc, and the one that needs the changes for ghc to finally build. These patches makes both version of ghc compile and ghci to work on my system, ghc-6.10.4 have also been tested to build and run other haskell-packages in tree (alex, happy, cabal, to name some).
We would have to wrap the 'sed', checking for USE="ghcbootstrap" too. What we'd like for hardend is to add the GHC_CFLAGS at install-time, as the binaries are built on a non-hardend system. However, they ghc wrappers from the binary already have the GHC_CFLAGS, and adding them again would mean that they would be added twice. Look at the binary for sparc, for example, which actually has other some values in GHC_CFLAGS, unlike the trivial x86 and amd64: exec "$executablename" -B"$topdir" -optc-mcpu=v9 -opta-mcpu=v9 ${1+"$@"} Where obviously "-optc-mcpu=v9 -opta-mcpu=v9" comes from GHC_CFLAGS. The flags would be added again if we'd do it directly in src_unpack like the patches above suggest. I guess those flags are harmless to add twice, but can this come back and bite us in another way somehow? Ideas? For a long-term solution I think we could send a patch to better support extra arguments like ours.
(In reply to comment #11) > We would have to wrap the 'sed', checking for USE="ghcbootstrap" too. > That could be a good idea. > What we'd like for hardend is to add the GHC_CFLAGS at install-time, as the > binaries are built on a non-hardend system. > Maybe this would work for USE="binary". But then GHC will not build on a hardened system (with USE="-binary -ghcbootstrap") since nopie will not be specified for GCC when GHC executes it while building. This is because GHC is built with the wrapper from the binary tarball unless USE="ghcbootstrap" and thus the wrapper does not while building GHC yet include the correct options for GCC when executed by GHC. > However, they ghc wrappers from the binary already have the GHC_CFLAGS, and > adding them again would mean that they would be added twice. > Should not be a problem. AFAIK both GCC and LD works that way that if you specify a option more then once or (at least some) conflicting options (i.e. like gcc -fstack-protector -fno-stack-protector) then the last option (-fno-stack-protector) is used by GCC. So this should not be a problem as long as GHC does not try to be smart and filters stuff. > Look at the binary for sparc, for example, which actually has other some values > in GHC_CFLAGS, unlike the trivial x86 and amd64: > exec "$executablename" -B"$topdir" -optc-mcpu=v9 -opta-mcpu=v9 ${1+"$@"} > Where obviously "-optc-mcpu=v9 -opta-mcpu=v9" comes from GHC_CFLAGS. > And I would ask why those are there. Looking at the ebuild it seems like those either are either added by GHCs own build system or are cruft from the host that built the sparc-tarball. As I see it the binary tarballs should not have any residue from the host system, because that would have the ghc-wrapper from the binary tarball try to be smarter then the system you are trying to build GHC on (i.e. if I build on a sparc-v8, do I really want any stage of my built GHC to be optimized for a sparc-v9?). If GHC really need -mcpu=v9 to build (and the builder of the binary tarball put it there for a reason) I would make the ebuild not let you build GHC on <sparc-v9, making sure in the ebuild that all references to CFLAGS="-mcpu/march" is at least v9, and be done with it. > The flags would be added again if we'd do it directly in src_unpack like the > patches above suggest. > > I guess those flags are harmless to add twice, but can this come back and bite > us in another way somehow? > As said earlier unless GHC tries to be smarter then the already installed GCC I do not see a problem. > Ideas? > > For a long-term solution I think we could send a patch to better support extra > arguments like ours. > Yeah, they already have a logic in the ./configure for ghc-6.10.4 to add some cflags on some systems (./configure places them in extra-gcc-opts and I guess they are used for the whole build) and to be able to add stuff with a --with-extra-gcc-opts would be a nice solution.
(In reply to comment #12) > (In reply to comment #11) > > We would have to wrap the 'sed', checking for USE="ghcbootstrap" too. > > > That could be a good idea. It makes sense in the overlay, but in portage I'm skeptical that it's a good idea to expose the ghcbootstrap USE-flag. > > > What we'd like for hardend is to add the GHC_CFLAGS at install-time, as the > > binaries are built on a non-hardend system. > > > Maybe this would work for USE="binary". > But then GHC will not build on a hardened system (with USE="-binary > -ghcbootstrap") since nopie will not be specified for GCC when GHC executes it > while building. > This is because GHC is built with the wrapper from the binary tarball unless > USE="ghcbootstrap" and thus the wrapper does not while building GHC yet include > the correct options for GCC when executed by GHC. Right, yes. I tried to explain my understanding, clearly I failed :) What I meant is that the installed GHC must support hardend, as well as the GHC that bootstraps GHC from source. Either way we need to add those flags, as the vanilla GHC binary won't have the required flags. I think we understand each other here. > > However, they ghc wrappers from the binary already have the GHC_CFLAGS, and > > adding them again would mean that they would be added twice. > > > Should not be a problem. AFAIK both GCC and LD works that way that if you > specify a option more then once or (at least some) conflicting options (i.e. > like gcc -fstack-protector -fno-stack-protector) then the last option > (-fno-stack-protector) is used by GCC. So this should not be a problem as long > as GHC does not try to be smart and filters stuff. I think this leads us to an issue if the flags are different the second time... read on. > > Look at the binary for sparc, for example, which actually has other some values > > in GHC_CFLAGS, unlike the trivial x86 and amd64: > > exec "$executablename" -B"$topdir" -optc-mcpu=v9 -opta-mcpu=v9 ${1+"$@"} > > Where obviously "-optc-mcpu=v9 -opta-mcpu=v9" comes from GHC_CFLAGS. > > > And I would ask why those are there. > Looking at the ebuild it seems like those either are either added by GHCs own > build system or are cruft from the host that built the sparc-tarball. This is slightly out of my field, as I don't have any of these sparc machines. I'll try to explain as this was once explained to me. All ghc binaries are built with the http://code.haskell.org/gentoo/gentoo-overlay/projects/build-ghc-bin.sh script. On sparc, it's edited in the CFLAGS variable to support an old sparc machine, so that the binary is backwards compatible. Thus you should be able to build a ghc version on both old and new sparc machines, and even install USE=binary. Maybe the -v9 has been confused, and -v8 should have been used instead. > As I see it the binary tarballs should not have any residue from the host > system, because that would have the ghc-wrapper from the binary tarball try to > be smarter then the system you are trying to build GHC on (i.e. if I build on a > sparc-v8, do I really want any stage of my built GHC to be optimized for a > sparc-v9?). Remember that we build the binaries by building ghc, emerge --buildpkgonly. If not to change more things, we need the binary to be universal when produced. A binary that doesn't change -march or that easily allow the ghc ebuild to edit those flags should be easier to handle. > > If GHC really need -mcpu=v9 to build (and the builder of the binary tarball put > it there for a reason) I would make the ebuild not let you build GHC on > <sparc-v9, making sure in the ebuild that all references to > CFLAGS="-mcpu/march" is at least v9, and be done with it. GHC doesn't need -mcpu=v9 afaik, it's simply a sparc user that set it to that version. > > The flags would be added again if we'd do it directly in src_unpack like the > > patches above suggest. > > > > I guess those flags are harmless to add twice, but can this come back and bite > > us in another way somehow? > > > As said earlier unless GHC tries to be smarter then the already installed GCC I > do not see a problem. If to replace the flags in the binary ghc-wrapper, the current 'sed' would add the new flags before the flags in the bundled ghc-wrapper, and thus be overrided by the host's settings that built the binary. > > > Ideas? > > > > For a long-term solution I think we could send a patch to better support extra > > arguments like ours. > > > Yeah, they already have a logic in the ./configure for ghc-6.10.4 to add some > cflags on some systems (./configure places them in extra-gcc-opts and I guess > they are used for the whole build) and to be able to add stuff with a > --with-extra-gcc-opts would be a nice solution. > Right, extra-gcc-opts is useful. If we add a extra-ghc-opts and let the ghc-wrapper use that, we could easily replace and edit all GHC_CFLAGS without using these sed scripts. Maybe that would be a solution worthy of pushing upstream.
(In reply to comment #13) > It makes sense in the overlay, but in portage I'm skeptical that it's a good > idea to expose the ghcbootstrap USE-flag. > Do you mean the the useflag ghcbootstrap should not be in the portage tree? > All ghc binaries are built with the > http://code.haskell.org/gentoo/gentoo-overlay/projects/build-ghc-bin.sh script. > On sparc, it's edited in the CFLAGS variable to support an old sparc machine, > so that the binary is backwards compatible. Thus you should be able to build a > ghc version on both old and new sparc machines, and even install USE=binary. > Maybe the -v9 has been confused, and -v8 should have been used instead. > http://code.haskell.org/gentoo/gentoo-haskell/projects/build-ghc-bin.sh Was this the script you referred to? AFAICS it does not set any CFLAGS except -O2 and -pipe so does the sparc builder set it by hand? Also if you read http://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html it says that v9 actually is the highest setting for mcpu, v7 is the least. So maybe ping the sparc team or the one building your sparc-tarballs and ask if they have a comment? I still cannot see however what -mcpu for sparc does there. As you said there is probably a reason for it, but that is probably another bug. > Remember that we build the binaries by building ghc, emerge --buildpkgonly. > If not to change more things, we need the binary to be universal when produced. > A binary that doesn't change -march or that easily allow the ghc ebuild to edit > those flags should be easier to handle. > Yes, I understand that the binary needs to be universal. And I guess that is what your script is for, so my point was already addressed (the wrapper form the binary tarball should not contain march/mcpu/mtune/other cruft unless needed). > If to replace the flags in the binary ghc-wrapper, the current 'sed' would add > the new flags before the flags in the bundled ghc-wrapper, and thus be > overrided by the host's settings that built the binary. > On the other hand, currently GHC is currently only builts with the settings of the binary, so even if the sed add those flags there it really should not be a problem while building. The settings from the binary will take priority over the settings set by the sed, but that will also only be a problem on platforms like sparc where the binary wrapper sets settings. And still that problem should only be sub-optimized code. Unless you are playing with -pie/-pg flags or other stuff that does not get along. > Right, extra-gcc-opts is useful. > If we add a extra-ghc-opts and let the ghc-wrapper use that, we could easily > replace and edit all GHC_CFLAGS without using these sed scripts. Maybe that > would be a solution worthy of pushing upstream. > Indeed, at least this sed feels a bit like a hack.
*** Bug 321589 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > (In reply to comment #13) > > It makes sense in the overlay, but in portage I'm skeptical that it's a good > > idea to expose the ghcbootstrap USE-flag. > > > Do you mean the the useflag ghcbootstrap should not be in the portage tree? Yes. I guess some users likes the ability to use it, but they are likely users of the overlay too. We get reports from time to time when users try to use ghcbootstrap in a wrong way. > Also if you read http://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html it says > that v9 actually is the highest setting for mcpu, v7 is the least. So maybe > ping the sparc team or the one building your sparc-tarballs and ask if they > have a comment? > I still cannot see however what -mcpu for sparc does there. As you said there > is probably a reason for it, but that is probably another bug. I've checked with the sparc guy. -v9 may be the latest, but it's 10+ years old and used on almost all machines. It doesn't make sense to use anything but -v9, and the gcc default of -v7 is crazy. His words :) In other words, we'll keep -v9. > > If to replace the flags in the binary ghc-wrapper, the current 'sed' would add > > the new flags before the flags in the bundled ghc-wrapper, and thus be > > overrided by the host's settings that built the binary. > > > On the other hand, currently GHC is currently only builts with the settings of > the binary, so even if the sed add those flags there it really should not be a > problem while building. > The settings from the binary will take priority over the settings set by the > sed, but that will also only be a problem on platforms like sparc where the > binary wrapper sets settings. > And still that problem should only be sub-optimized code. Unless you are > playing with -pie/-pg flags or other stuff that does not get along. Ok, I think I understood what you mean. I'll get back to this asap I can, and we'll get the recent versions to work this way.
I like the patch, but '-fPIC' non-filtering makes me feel uneasy. It should affect C part of ghc and all generated by GHC files in C backend (-fvia-C option). Some random tests on non-hardened gentoo: # cat a.hs main = print "hello" x86/ghc-6.10.4 (breakage): # ghc -optc-fPIC -fvia-C --make a.hs [1 of 1] Compiling Main ( a.hs, a.o ) Warning: retaining unknown function `__i686.get_pc_thunk.bx' in output from C compiler Prologue junk?: .type rv2_entry, @function rv2_entry: call __i686.get_pc_thunk.bx addl $_GLOBAL_OFFSET_TABLE_, %ebx # 22 "/tmp/ghc22077_0/ghc22077_0.hc" 1 amd64/ghc-6.10.4 (success): compiles/links ppc64/ghc-6.10.4 (success): compiles/links So I have a bunch of questions: 1. Is there reason to try to use -fPIC flag? 2. Does hardened explicitely pass '-fPIC' to CFLAGS and something breaks if you filter it? 3. Can ghc be built/used without '-fPIC' changes in the patch? I'm afraid it can also bring harm to other arches. The rest of patch looks good.
(In reply to comment #17) Sorry I do not actually know how to an swear your post more then maybe with "Sorry you are wrong and are misundrstanding the problems here". If I was about to try to explain why stuff would not break by removing the filter-flags it would be by try to tell that filter-flags -fPIE/-fPIC/-PIE/-PIC/-pie/-pic does not filter CFLAGS. It adds the -nopie to CFLAGS, telling the hardened compiler to not try to make PIC/PIE files out of what was sent it's way. Now on hardend we currently we have two failures with GHC: The C-code and the Haskell code. The C-code fails because on a hardened system GHC (as in the buildsystem, not the compiler) tries to build the C-files with -nopie (which works) but later tries to link the resulting files without -nopie. This leads to the linker trying to make a PIC/PIE-file out of it, creating TEXTRELs on x86 and breaking on most other arches (including amd64). Now we could either patch the buildsystem to pass -nopie to gcc also while linking (big task), or we could build and link all native C-code as PIC/PIE which also actually works by removing the filter-flags (since ghc never touches this code). The Haskell code has completely other problems. GHC (as in the compiler) does not know anything about PIC/PIE on a hardened system. It generates c-code out of the haskell code, and fires it away in GCCs general direction. Because GCC is not told otherwise it tries to create PIC/PIE out of the code. Since GHC does not handle this it leads to TEXTRELs on x86, and buildfailures on most other arches. This is fixed by telling GHC to send -nopie to GCC while building and linking so it knows it should not try to make PIC/PIE code out of it. On a non-hardened system the filter-flags just removes any presens of a -fPIC from the CFLAGS handed to the ebuild. And there should not even be a -fPIC in CFLAGS in make.conf to begin with, as no package would be able to build/link on a system like that. So "filter-flags -fPIC" does in reality only make changes on a hardened-system Also for reference all code changes I propose here is double tested on a amd64 hardened system. If any of those problems you proposed would actually manifest themselves GHC would not be able to rebuild itself, even less build anything else haskell on this system. I propose we do add all the changes to a -r# and see if it actually breaks anything for anyone.
(In reply to comment #18) This is indeed trickier than it looks at first. > I propose we do add all the changes to a -r# and see if it actually breaks > anything for anyone. I've taken your changes to the gentoo haskell overlay for testing, and also added the testing for USE=ghcbootstrap. It seems to work well, so it'll be copied into portage soon. We expect ghc 6.12.3 to be released any day now, and it'll also get the same patches.
(In reply to comment #18) > filter-flags -fPIE/-fPIC/-PIE/-PIC/-pie/-pic does not filter CFLAGS. It adds the -nopie to CFLAGS I see. Thank you.
Changes gone to gentoo-x86 (ghc-6.12.3) and seem to work on hardened. (also requred changes from bug #299709)
