remove unnecessary PaX detection

[thestinger]

Rust no longer has support for JIT compilation, so it doesn't currently
require a PaX MPROTECT exception. The extended attributes are preferred
over modifying the binaries so it's not actually going to work on most
systems like this anyway.

If JIT compilation ends up being supported again, it should handle this
by always applying the exception via an extended attribute without
performing auto-detection of PaX on the host. The paxctl tool is only
necessary with the older method involving modifying the ELF binary.

[wizeman]

It seems like MPROTECT still needs to be disabled after all. Specifically, running make test fails with a cannot make segment writable for relocation: Permission denied error unless MPROTECT is disabled in the resulting binary of the relocation-model test, when using the default or static relocation models:

diff --git a/src/test/run-make/relocation-model/Makefile b/src/test/run-make/relocation-model/Makefile
index 2fcdd32..2d9ddb0 100644
--- a/src/test/run-make/relocation-model/Makefile
+++ b/src/test/run-make/relocation-model/Makefile
@@ -5,9 +5,11 @@ all:
 >      $(call RUN,foo)
$
 >      $(RUSTC) -C relocation-model=default foo.rs
+>      paxctl -czexm $(TMPDIR)/foo
 >      $(call RUN,foo)
$
 >      $(RUSTC) -C relocation-model=static foo.rs
+>      paxctl -czexm $(TMPDIR)/foo
 >      $(call RUN,foo)
$
 >      $(RUSTC) -C relocation-model=default --crate-type=dylib foo.rs

The tests pass if the patch above is used, but I'm not sure if this should only be patched in the test's Makefile or if rustc itself should call paxctl. This was on a 64-bit system, BTW.

Additionally, if Rust is compiled with a 32-bit userland on a 64-bit kernel (which I'm using for testing), I can't even get rustc to compile, as it fails with a similar error during the build:

[q�[pbuilding i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libmorestack.a
cp: i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libmorestack.a
�[q�[pbuilding i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libcompiler-rt.a
cp: i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libcompiler-rt.a
�[q�[pbuilding i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/stamp.core
rustc: i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libcore
i686-unknown-linux-gnu/stage1/bin/rustc: error while loading shared libraries: /tmp/nix-build-rustc-0.12.0-pre-961-g93c85eb.drv-0/git-export/i686-unknown-linux-gnu/stage1/lib/librustrt-4e7c5e5c.so: cannot make segment writable for relocation: Permission denied
make: *** [i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/stamp.core] Error 127

[wizeman]

The following FAQ has more info about this issue:

http://wiki.gentoo.org/wiki/Hardened/FAQ#I_keep_getting_the_message:_.22error_while_loading_shared_libraries:_cannot_make_segment_writable_for_relocation:_Permission_denied..22_What_does_this_mean.3F

Based on my reading of the FAQ, disabling MPROTECT is probably not the best way to handle the errors above, although I'm not sure what is the best way to fix it.

I'm not using Gentoo, BTW.

[thestinger]

The test case is broken because it's mixing the static relocation model with dynamic linking.

[thestinger]

It seems like MPROTECT still needs to be disabled after all.

The issue you're reporting has nothing to do with this old paxctl code used to mark the Rust compiler binaries since they included a JIT compiler.