Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#10188 closed defect (fixed)

mpir spkg needs update for Fedora 14

Reported by: vbraun Owned by: tbd
Priority: major Milestone: sage-4.6.1
Component: packages: standard Keywords: execstack executable stack
Cc: leif, jdemeyer Merged in: sage-4.6.1.alpha3
Authors: Volker Braun Reviewers: Leif Leonhardy
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by leif)

MPIR builds libraries that have the "executable stack" flag. This breaks in Fedora 14 which tightened SELinux rules to disallow executable stack libraries by default.

Note that the MPIR libraries do not need executable stack permissions, the flag is set erroneously. Probably because gcc can't figure it out automatically for assembler code.

Updated spkg is here:

http://www.stp.dias.ie/~vbraun/Sage/spkg/mpir-1.2.2.p2.spkg

The only change was that the spkg-install tested whether the execstack utility is installed and then used it to clear the flag after the make step.

The new spkg now simply adds -Wl,-z,noexecstack to LDFLAGS on Linux.

Attachments (1)

mpir-spkg-install.diff (1.9 KB) - added by vbraun 9 years ago.
Updated patch

Download all attachments as: .zip

Change History (20)

comment:1 Changed 9 years ago by fbissey

I pointed out the executable stack problem of mpir a while ago. They inherited from gmp actually. In actual fact that should be fixed in mpir. In Gentoo we have a patch but we don't know if it removes the executable stack on all cpu models that are affected.

comment:2 Changed 9 years ago by vbraun

  • Status changed from new to needs_review

I agree that it needs fixing in mpir. The libgcrypt, for example, ships with an m4/noexecstack.m4 macro. That would be a good starting point for fixing up mpir's autotools, I think.

comment:3 Changed 9 years ago by fbissey

I will check that. The main problem in mpir is there is some code in yasm assembler and some in GNU assembler (and some more in C but these are not a problem) depending on the CPU. In Gentoo we apply the following to the source of mpir-2.X.X:

	for i in $(find . -type f -name '*.asm') ; do
		# TODO: why does this not work without the following echo ???
		echo $i >/dev/null
		cat >> $i <<-EOF
			#if defined(__linux__) && defined(__ELF__)
			.section .note.GNU-stack,"",%progbits
			#endif
		EOF
	done

	for i in $(find . -type f -name '*.as') ; do
		echo $i >/dev/null
		cat >> $i <<-EOF
			%ifidn __OUTPUT_FORMAT__,elf
			section .note.GNU-stack noalloc noexec nowrite progbits
			%endif
		EOF
	done

We do this following the recommendation from http://www.gentoo.org/proj/en/hardened/gnu-stack.xml The file naming is somewhat reverse from what we expected if I remember well.

comment:4 Changed 9 years ago by leif

  • Cc leif added

comment:5 Changed 9 years ago by leif

$ env LDFLAGS="-Wl,-z,noexecstack" ./sage -f spkg/standard/mpir-1.2.2.p1.spkg &>/dev/null && execstack -q local/lib/lib{gmp,mpir}*.so* local/lib/libgmp.so
- local/lib/libgmp.so.3
- local/lib/libgmp.so.3.4.6
- local/lib/libgmpxx.so
- local/lib/libgmpxx.so.3
- local/lib/libgmpxx.so.3.1.6
- local/lib/libmpir.so
- local/lib/libmpir.so.3
- local/lib/libmpir.so.3.4.6
- local/lib/libmpirxx.so
- local/lib/libmpirxx.so.3
- local/lib/libmpirxx.so.3.1.6

works for me as well...

comment:6 Changed 9 years ago by leif

And also:

$ env LDFLAGS="-Wl,-z,noexecstack" ./sage -f ../spkgs/mpir-2.1.1.spkg &>/dev/null && execstack -q local/lib/lib{gmp,mpir}*.so* local/lib/libgmp.so
- local/lib/libgmp.so
- local/lib/libgmp.so.8
- local/lib/libgmp.so.8.2.1
- local/lib/libgmpxx.so
- local/lib/libgmpxx.so.2
- local/lib/libgmpxx.so.2.2.9
- local/lib/libmpir.so
- local/lib/libmpir.so.8
- local/lib/libmpir.so.8.2.1
- local/lib/libmpirxx.so
- local/lib/libmpirxx.so.2
- local/lib/libmpirxx.so.2.2.9
- local/lib/libgmp.so

comment:7 follow-up: Changed 9 years ago by vbraun

Yes. Or pass --noexecstack to gcc. For the official mpir patch I would suggest to use the aforementioned noexecstack.m4 which checks that the linker understands the noexecstack option.

I'm not sure if sticking it unconditionally into the spkg-install is the way to go. I think its supported since gcc-3.4, so that *probably* covers all gcc versions that can compile Sage. Not sure about Solaris...

comment:8 in reply to: ↑ 7 ; follow-up: Changed 9 years ago by leif

Replying to vbraun:

Yes. Or pass --noexecstack to gcc. For the official mpir patch I would suggest to use the aforementioned noexecstack.m4 which checks that the linker understands the noexecstack option.

I'm not sure if sticking it unconditionally into the spkg-install is the way to go. I think its supported since gcc-3.4, so that *probably* covers all gcc versions that can compile Sage. Not sure about Solaris...

Well, we at least currently need it on Linux only (Fedora 14), where we can assume a GNU linker.

By the way, the Fedora users could simply change / customize their policy, or disable SELinux... ;-)

comment:9 follow-up: Changed 9 years ago by leif

It's IMHO cleaner (and more robust) to add

case "$UNAME" in
    Linux) # implies a GNU linker
        LDFLAGS="$LDFLAGS -Wl,z,noexecstack"
        # already exported by sage-env
        ;;
    # perhaps other platforms, too
esac

Note that the above doesn't depend on the GCC version (or the compiler in general; the flag to pass options to the linker might of course differ though, but that's probably handled by libtool).

Even the Sun linker might support that, though it is currently not an issue on [Open]Solaris.

Older versions of the GNU linker will silently ignore this option, i.e. its parameter (noexecstack); on such systems it is unlikely that requiring an executable stack will cause problems anyway.

Also, using the execstack tool requires having it installed on any build system one builds bdists on, if they are also targeted at e.g. Fedora 14, or other SELinux-enabled systems.

    type -P execstack &>/dev/null && ...

won't raise an error or give a warning in such cases.

Perhaps the MPIR developers will fix this upstream in a quick 2.1.4, such that it will be a non-issue soon, since we're going to upgrade MPIR anyway.

Nevertheless, feel free to send them a patch fixing their autotools/configure. ;-)

comment:10 in reply to: ↑ 8 Changed 9 years ago by leif

Replying to leif:

By the way, the Fedora users could simply change / customize their policy, or disable SELinux... ;-)

This had been necessary for at least earlier versions of Sage because of text relocations in the PARI library IIRC. Sage's README.txt contains a note on that:

SELINUX
--------

On Linux, if you get this error message:

    " restore segment prot after reloc: Permission denied "

the problem is probably related to SELinux. See the following URL for
further information:

    http://www.ittvis.com/services/techtip.asp?ttid=3092

comment:11 in reply to: ↑ 9 Changed 9 years ago by leif

Replying to leif:

It's IMHO cleaner (and more robust) to add

case "$UNAME" in
    Linux) # implies a GNU linker
        LDFLAGS="$LDFLAGS -Wl,z,noexecstack"
        # already exported by sage-env
        ;;
    # perhaps other platforms, too
esac

You will have noticed the missing "-", should read:

        LDFLAGS="$LDFLAGS -Wl,-z,noexecstack"

Changed 9 years ago by vbraun

Updated patch

comment:12 Changed 9 years ago by vbraun

I have updated the mpir-1.2.2.p2.spkg to use the LDFLAGS method instead of the exectstack tool.

comment:13 follow-up: Changed 9 years ago by leif

  • Cc jdemeyer added
  • Description modified (diff)
  • Keywords execstack executable stack added
  • Reviewers set to Leif Leonhardy
  • Status changed from needs_review to positive_review

Although both the commit message and the changelog entry lack a back-reference to this ticket, positive review.

I think we can safely (and should) merge this into 4.6.1, since unfortunately the MPIR upgrade (#8664) is again delayed by trouble with the necessary GMP-ECM upgrade (#5847) for a couple of reasons (mainly weird MacOS X PPC issues).

comment:14 Changed 9 years ago by leif

P.S.:

The already tested and positively reviewed MPIR 2.1.3.p1 spkg at #8664 contains the same fix, cf. http://trac.sagemath.org/sage_trac/attachment/ticket/8664/trac_8664-mpir-2.1.1_vs._2.1.3.p0-spkg.patch:

    ...
    Linux) 
        # Work around (erroneously) set "executable stack" attributes, 
        # causing runtime errors on Fedora 14 and other SELinux- 
        # enabled systems: 
        LDFLAGS="$LDFLAGS -Wl,-z,noexecstack" 
        export LDFLAGS # perhaps redundant, but safe(r)

        ... 

comment:15 follow-up: Changed 9 years ago by vbraun

The spkg from #8664 will not be merged in sage-4.6.1. We should still pull in the spkg from this package and replace it in sage-4.6.2 with the one from #8664.

comment:16 in reply to: ↑ 15 Changed 9 years ago by leif

Replying to vbraun:

The spkg from #8664 will not be merged in sage-4.6.1. We should still pull in the spkg from this package and replace it in sage-4.6.2 with the one from #8664.

That's what I was trying to say... ;-)

comment:17 in reply to: ↑ 13 Changed 9 years ago by leif

Replying to leif:

I think we can safely (and should) merge this into 4.6.1, since unfortunately the MPIR upgrade (#8664) is again delayed by trouble with the necessary GMP-ECM upgrade (#5847) for a couple of reasons (mainly weird MacOS X PPC issues).

A new GMP-ECM spkg (6.3.p2) is ready for review / testing at #5847.

comment:18 Changed 9 years ago by jdemeyer

  • Merged in set to sage-4.6.1.alpha3
  • Resolution set to fixed
  • Status changed from positive_review to closed

comment:19 Changed 9 years ago by leif

Just for the record:

This is now fixed in MPIR 2.2.0, released today.

Note: See TracTickets for help on using tickets.