mpir spkg needs update for Fedora 14

[vbraun]

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.

CC: @nexttime @jdemeyer

Component: packages: standard

Keywords: execstack executable stack

Author: Volker Braun

Reviewer: Leif Leonhardy

Merged: sage-4.6.1.alpha3

Issue created by migration from https://trac.sagemath.org/ticket/10188

[kiwifb]

comment:1

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.

[vbraun]

comment:2

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.

[kiwifb]

comment:3

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.

[nexttime]

comment:5

$ 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...

[nexttime]

comment:6

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

[vbraun]

comment:7

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...

[nexttime]

comment:8

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... ;-)

[nexttime]

comment:9

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. ;-)

[nexttime]

comment:10

Replying to @nexttime:

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

[nexttime]

comment:11

Replying to @nexttime:

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"

[vbraun]

Updated patch

[vbraun]

comment:12

Attachment: mpir-spkg-install.diff.gz

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

[nexttime]

Changed keywords from none to execstack executable stack

[nexttime]

Reviewer: Leif Leonhardy

[nexttime]

comment:13

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).

[nexttime]

comment:14

P.S.:

The already tested and positively reviewed MPIR 2.1.3.p1 spkg at #8664 contains the same fix, cf. https://github.com/sagemath/sage/files/ticket8664/7d5ea4aeb52e253c96d8f00e56a0f2f1.gz

    ...
    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)

        ... 

[vbraun]

comment:15

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.

[nexttime]

comment:16

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... ;-)

[nexttime]

comment:17

Replying to @nexttime:

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.

[jdemeyer]

Merged: sage-4.6.1.alpha3

[nexttime]

comment:19

Just for the record:

This is now fixed in MPIR 2.2.0, released today.