Created attachment 386264 [details, diff] Patch for cabal-install-1.18.0.3.ebuild /usr/bin/cabal fails to run on hardened profiles with mprotect enabled because it tries to create a rwx memory page: $ eix -ce cabal-install [I] dev-haskell/cabal-install (1.18.0.3{tbz2}[1]@08/10/14): The command-line interface for Cabal and Hackage [1] "gentoo-haskell" /mnt/portage/layman/haskell $ cabal cabal: failed to create OS thread: Operation not permitted $ strace cabal |& tail -7 mmap(NULL, 8392704, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = -1 EPERM (Operation not permitted) write(2, "cabal: ", 7cabal: ) = 7 write(2, "failed to create OS thread", 26failed to create OS thread) = 26 write(2, ": Operation not permitted\n", 26: Operation not permitted ) = 26 exit_group(1) = ? +++ exited with 1 +++ I'm attaching a patch for dev-haskell/cabal-install-1.18.0.3, the newest 1.18 version corresponding to the latest stable dev-haskell/cabal-1.18.1.2. Tested locally, works for me. This issue possibly applies to other cabal-install versions as well.
Created attachment 386266 [details] emerge --info
Can you get a bactrace in gdb to that mmap?
Working on it, rebuilding things for debugging.
$ gdb -quiet cabal Reading symbols from /usr/bin/cabal...Reading symbols from /usr/lib64/debug/usr/bin/cabal.debug...done. done. (gdb) break mmap if $rdx == 7 Breakpoint 1 at 0x405e20 (gdb) run Starting program: /usr/bin/cabal warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Breakpoint 1, mmap64 () at ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) bt #0 mmap64 () at ../sysdeps/unix/syscall-template.S:81 #1 0x000003fff79afd74 in allocate_stack (stack=<synthetic pointer>, pdp=<synthetic pointer>, attr=0x3ffffff9210) at allocatestack.c:513 #2 __pthread_create_2_1 (newthread=newthread@entry=0x3ffffff92b8, attr=attr@entry=0x0, start_routine=start_routine@entry=0xd60db0 <workerStart>, arg=arg@entry=0x1159220) at pthread_create.c:495 #3 0x0000000000d6ca1e in createOSThread (pId=pId@entry=0x3ffffff92b8, startProc=startProc@entry=0xd60db0 <workerStart>, param=param@entry=0x1159220) at rts/posix/OSThreads.c:119 #4 0x0000000000d612b2 in startWorkerTask (cap=0x112e440 <MainCapability>) at rts/Task.c:451 #5 0x0000000000d5d0f0 in releaseCapability_ (always_wakeup=rtsFalse, cap=0x112e440 <MainCapability>) at rts/Capability.c:494 #6 releaseCapability_ (cap=cap@entry=0x112e440 <MainCapability>, always_wakeup=always_wakeup@entry=rtsFalse) at rts/Capability.c:445 #7 0x0000000000d646fb in suspendThread (reg=0x112e598 <MainCapability+344>, interruptible=rtsFalse) at rts/Schedule.c:2219 #8 0x0000000000d411be in s3GC_info () #9 0x0000000000000000 in ?? () (gdb)
Created attachment 386464 [details] Backtrace for gtk/glib mmap Hmm, I also have problems with with an RWX mmap doing normal development on an application that uses dev-haskell/gtk. Backtrace attached. Maybe something in my environment is wrong (incompatible kernel PAX options say).
(In reply to Khumba from comment #5) > Created attachment 386464 [details] > Backtrace for gtk/glib mmap > > Hmm, I also have problems with with an RWX mmap doing normal development on > an application that uses dev-haskell/gtk. Backtrace attached. Maybe > something in my environment is wrong (incompatible kernel PAX options say). Yeah, what I don't like in your backtraces is that mmap function is called by 'pthread_create/allocate_stack' in glibc itself. How long ago did you switch to hardened? It's usually a set of simple bugs that manifest soon after conversion. Should be fixed by rebuilding gcc/glibc. Could it be that you didn't rebuild gcc/glibc with USE=hardened in correct order? I see you are using binary packages, be careful to check they not trick you into keeping old binary versions after profile conversion.
Hmm, this is a fresh install from stage3-amd64-hardened-20140619.tar.bz2 this past Monday, and I just completed rebuilding every package this weekend (to add CFLAGS="-ggdb"; except for a few virtuals)! The one thing I did with this install that I haven't done before is install it from within NixOS, not sure how that could affect the result. Hardened install from a non-hardened environment outside the chroot isn't a problem right? I'm sure I've had Hardened and Haskell happy together in the past. I noticed that in my rebuilding of everything, gcc was rebuilt after glibc and binutils, so I rebuilt the latter two just in case, but it didn't seem to help (didn't rebuild world again though). I really only use binary packages for backup purposes, so I don't think that's playing into it here. > Yeah, what I don't like in your backtraces is that > mmap function is called by 'pthread_create/allocate_stack' > in glibc itself. Ah, glibc shouldn't ask for W|X normally on hardened? That makes sense :). Looking into why that is. Thanks for the help and quick responses.
Created attachment 387186 [details] cabal-install-1.18.0.3 build.log I've been busy and haven't looked into this much more so far, but I noticed the following in the build log for cabal-install. Is this significant? --- >>> Completed installing cabal-install-1.18.0.3 into /mnt/portage/build/portage/dev-haskell/cabal-install-1.18.0.3/image/ strip: x86_64-pc-linux-gnu-strip --strip-unneeded -R .comment -R .GCC.command.line -R .note.gnu.gold-version usr/bin/cabal ecompressdir: bzip2 -9 /usr/share/doc * QA Notice: The following files contain writable and executable sections * Files with such sections will not work properly (or at all!) on some * architectures/operating systems. A bug should be filed at * http://bugs.gentoo.org/ to make sure the issue is fixed. * For more information, see http://hardened.gentoo.org/gnu-stack.xml * Please include the following list of files in your report: * Note: Bugs should be filed for the respective maintainers * of the package in question and not hardened@g.o. * RWX --- --- usr/bin/cabal
I see that cabal-install.cabal has "ghc-options: -threaded". When I make a trivial Main.hs with: module Main where main = putStrLn "Hello." and compile it with "ghc -o Main Main.hs" it works, but "ghc -threaded -o Main Main.hs" fails with the same error (Main: failed to create OS thread: Operation not permitted). Does the threaded runtime not work on hardened? Will try upgrading from ghc-7.6.3-r1 to 7.8.3 to see if that helps any.
To be precise, running the resulting binary gives the error, not the compilation process.
Yes, doing the same test with ghc-7.8.3 and -threaded works perfectly fine. The GNU_STACK section of the binary produced by 7.6.3 is RWX whereas the GNU_STACK section of the binary produced by 7.8.3 is only RW.
Thanks for the detailed research! It's interesting because we have a hack for it in ghc-7.6.3 ebuild: > case $($(tc-getAS) -v 2>&1 </dev/null) in > *"GNU Binutils"*) # GNU ld > append-ghc-cflags compile assemble -Wa,--noexecstack > ;; > esac It used to work (I think last ghc i used on hardened was 7.4.*), and ghc-7.8.3 started to mark stack properly on it's own, thus we don't to it on 7.8.* at all. I think the easies way to detect where execstack comes from is to scan for ghc's installed binaries: https://wiki.gentoo.org/wiki/Hardened/GNU_stack_quickstart#Finding_ELFs_that_ask_for_an_executable_stack (or just use FEATURES="strict stricter" emerge -1 ghc, it should also run scanelf) that will ease tracking of lost CFLAGS/ASFLAGS. Maybe ghc's threaded part of Makefile is slightly broken and needs a tweak.
Created attachment 387560 [details] Failed QA check for ghc-7.6.3-r1 Alright, thanks Sergei, 'FEATURES="keeptemp keepwork strict stricter" emerge -1 ghc' it is. Lots of warnings from this one.
I compiled two binaries, Hello-unthreaded and Hello-threaded, as above and tested them on three different virtualboxes, x86+segmexec, x86+pageexec, and amd64+pageexec, and the only one to abort like this was Hello-threaded on amd64+pageexec (surprisingly x86+pageexec was fine).
*** Bug 555844 has been marked as a duplicate of this bug. ***
*** Bug 555552 has been marked as a duplicate of this bug. ***
*** Bug 556674 has been marked as a duplicate of this bug. ***
Is there any news on this? I just tried updating a system that's been down for maintenance for a couple of months, and it appears that, due to the way that #537500 was fixed, you really can't emerge any Haskell packages on a stable system with MPROTECT. A simple workaround is to have haskell-cabal.eclass inherit pax-utils and just do "pax-mark m setup" at the end of make_setup.
(In reply to Sean Santos from comment #18) > Is there any news on this? I just tried updating a system that's been down > for maintenance for a couple of months, and it appears that, due to the way > that #537500 was fixed, you really can't emerge any Haskell packages on a > stable system with MPROTECT. > > A simple workaround is to have haskell-cabal.eclass inherit pax-utils and > just do "pax-mark m setup" at the end of make_setup. Did you by chance try newer ghc version? 7.8 or even 7.10? If people are happy with 7.8+ we should just stabilize it.
I have not tried 7.8 since I'm on stable, but I can give it a shot. (I've just moved from Denver to Seattle, hence the delay in replying.)
GHC 7.8 seems OK, though I had to fiddle with figuring out which other packages to bump at the same time (e.g. haddock, cabal).
(In reply to Sean Santos from comment #21) > GHC 7.8 seems OK, though I had to fiddle with figuring out which other > packages to bump at the same time (e.g. haddock, cabal). Thanks for the test! I'll grab a set of packages for 7.8 to stabilise.
Thanks all who helped to track this bug down, had a courage to test unstable ghc and just being patient to make it happen! Stabilised ghc-7.8 and friends as: [sf] ~/portage/gentoo/dev-haskell/glade:git log --oneline ffc2ee0..6b25137 | cat 6b25137 dev-haskell/glade: amd64 ppc ppc64 sparc x86 stable, bug #524790 006e22d dev-haskell/gtk: amd64 ppc ppc64 sparc x86 stable, bug #524790 389c387 dev-haskell/gio: amd64 ppc ppc64 sparc x86 stable, bug #524790 b4c3b7a dev-haskell/pango: amd64 ppc ppc64 sparc x86 stable, bug #524790 02d41ac dev-haskell/cairo: amd64 ppc ppc64 sparc x86 stable, bug #524790 591a38a dev-haskell/dbus: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790 ce3e131 dev-haskell/chell: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790 032d132 dev-haskell/patience: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790 0f645bf dev-haskell/options: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790 9f725e7 dev-haskell/monads-tf: ia64 ppc64 stable, bug #524790 7000a34 dev-haskell/chell-quickcheck: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790 705a26b dev-haskell/glib: amd64 ppc ppc64 sparc x86 stable, bug #524790 6acfd70 dev-haskell/cgi: fix lower bound bb46c1c dev-haskell/mtl: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790 8d20697 dev-haskell/mtl: version bump, latest of 2.1 branch 7005a41 dev-haskell/pandoc-citeproc: amd64 x86 stable, bug #524790 111318e dev-haskell/xml-conduit: amd64 x86 stable, bug #524790 198ddd9 dev-haskell/pretty-show: amd64 x86 stable, bug #524790 e604a91 dev-haskell/haskell-lexer: amd64 x86 stable, bug #524790 8f06aee dev-haskell/mtl-compat: infer flags to pick proper mtl 8fd2089 dev-haskell/cgi: alpha amd64 ppc sparc x86 stable, bug #524790 4c24020 dev-haskell/exceptions: alpha ppc sparc stable, bug #524790 bc1b580 dev-haskell/mtl-compat: alpha amd64 ppc sparc x86 stable, bug #524790 c598674 dev-haskell/transformers-compat: alpha ppc sparc stable, bug #524790 0d27b48 dev-haskell/multipart: alpha amd64 ppc sparc x86 stable, bug #524790 f0b8119 dev-haskell/mtl-compat: Backported Control.Monad.Except module from dev-haskell/mtl-2.2. a6bbedd dev-haskell/encoding: amd64 x86 stable, bug #524790 20adbb0 dev-haskell/cabal-install: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790 c4cd178 dev-haskell/cabal-install: version bump for ghc-7.8.4 f888690 dev-haskell/hxt: amd64 x86 stable, bug #524790 b3a1953 dev-haskell/hxt-regex-xmlschema: amd64 x86 stable, bug #524790 a325be9 dev-haskell/monadcatchio-mtl: alpha amd64 ppc sparc x86 stable, bug #524790 1641f90 dev-haskell/monadcatchio-transformers: alpha amd64 ppc sparc x86 stable, bug #524790 1e71e8f dev-haskell/monads-tf: alpha ppc sparc stable, bug #524790 2063b14 dev-haskell/hashed-storage: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790 2362746 dev-haskell/lcs: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790 ae817ee dev-haskell/frown: port to ghc-7.8, bug #524790 547b5ec dev-haskell/text-icu: amd64 x86 stable, bug #524790 37a603c dev-haskell/doctest: amd64 x86 stable, bug #524790 77ea16d dev-haskell/base-compat: amd64 x86 stable, bug #524790 d5d8cf1 dev-haskell/errorcall-eq-instance: amd64 x86 stable, bug #524790 c5e6921 dev-haskell/transformers-compat: enable stable transformers-0.3 depend by default (used by stable ghc-7.8.4) 1e43abb dev-haskell/http-attoparsec: amd64 x86 stable, bug #524790 c7cad57 dev-haskell/hslogger: amd64 x86 stable, bug #524790 053075c dev-haskell/zlib-conduit: amd64 x86 stable, bug #524790 c128372 dev-haskell/vector: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790 646ba83 dev-haskell/network-conduit: amd64 x86 stable, bug #524790 aad36ff dev-haskell/haddock: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790 f498be3 dev-haskell/terminfo: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790 9978b9e dev-haskell/hpc: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790 d45dfc9 dev-haskell/haskeline: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790 0a16622 dev-haskell/haskeline: add haskeline version bundled with ghc-7.8.4 b2c78bc dev-haskell/deepseq: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790 3466b24 dev-haskell/cabal: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790 6e8a4a3 dev-haskell/cabal: add Cabal version bundled with ghc-7.8.4 6c08c1e dev-lang/ghc: alpha amd64 ia64 ppc ppc64 sparc x86 stable, bug #524790
Thanks Sergei and Sean, very happy to see newer Haskell packages stabilized.
*** Bug 561036 has been marked as a duplicate of this bug. ***
*** Bug 554676 has been marked as a duplicate of this bug. ***
*** Bug 548482 has been marked as a duplicate of this bug. ***
