Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 907799 - dev-lang/rust-1.69.0-r1 - compile error - libLLVM-15-rust-1.68.2-stable.so: cannot enable executable stack as shared object
Summary: dev-lang/rust-1.69.0-r1 - compile error - libLLVM-15-rust-1.68.2-stable.so: c...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo Rust Project
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 911589
  Show dependency tree
 
Reported: 2023-06-03 18:12 UTC by cilly
Modified: 2024-02-14 10:26 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build log (build.log,9.97 KB, application/octet-stream)
2023-06-03 18:12 UTC, cilly
Details
eclass debug log (eclass-debug.log,10.47 KB, text/plain)
2023-06-03 18:12 UTC, cilly
Details
emerge --info (emerge-info.txt,7.11 KB, text/plain)
2023-06-03 18:13 UTC, cilly
Details

Note You need to log in before you can comment on or make changes to this bug.
Description cilly 2023-06-03 18:12:01 UTC
Created attachment 863141 [details]
build log

This version has some problems compiling.

The earlier stable version rust-1.66.1 works fine and does compile.

>>> Compiling source in /var/tmp/portage/dev-lang/rust-1.69.0-r1/work/rustc-1.69.0-src ...
Building bootstrap
running: /var/tmp/portage/dev-lang/rust-1.69.0-r1/work/rust-stage0/bin/cargo build --manifest-path /var/tmp/portage/dev-lang/rust-1.69.0-r1/work/rustc-1.69.0-src/src/bootstrap/Cargo.toml --verbose --verbose --locked --frozen
[0m[0m[1m[31merror[0m[1m:[0m process didn't exit successfully: `/var/tmp/portage/dev-lang/rust-1.69.0-r1/work/rust-stage0/bin/rustc -vV` (exit status: 127)
--- stderr
/var/tmp/portage/dev-lang/rust-1.69.0-r1/work/rust-stage0/bin/rustc: error while loading shared libraries: libLLVM-15-rust-1.68.2-stable.so: cannot enable executable stack as shared object requires: Permission denied

Traceback (most recent call last):
  File "/var/tmp/portage/dev-lang/rust-1.69.0-r1/work/rustc-1.69.0-src/./x.py", line 29, in <module>
    bootstrap.main()
  File "/var/tmp/portage/dev-lang/rust-1.69.0-r1/work/rustc-1.69.0-src/src/bootstrap/bootstrap.py", line 946, in main
    bootstrap(args)
  File "/var/tmp/portage/dev-lang/rust-1.69.0-r1/work/rustc-1.69.0-src/src/bootstrap/bootstrap.py", line 912, in bootstrap
    build.build_bootstrap(args.color, verbose_count)
  File "/var/tmp/portage/dev-lang/rust-1.69.0-r1/work/rustc-1.69.0-src/src/bootstrap/bootstrap.py", line 795, in build_bootstrap
    run(args, env=env, verbose=self.verbose, cwd=self.rust_root)
  File "/var/tmp/portage/dev-lang/rust-1.69.0-r1/work/rustc-1.69.0-src/src/bootstrap/bootstrap.py", line 167, in run
    raise RuntimeError(err)
RuntimeError: failed to run: /var/tmp/portage/dev-lang/rust-1.69.0-r1/work/rust-stage0/bin/cargo build --manifest-path /var/tmp/portage/dev-lang/rust-1.69.0-r1/work/rustc-1.69.0-src/src/bootstrap/Cargo.toml --verbose --verbose --locked --frozen
 [31;01m*[0m ERROR: dev-lang/rust-1.69.0-r1::gentoo failed (compile phase):
 [31;01m*[0m   (no error message)
 [31;01m*[0m 
 [31;01m*[0m Call stack:
 [31;01m*[0m     ebuild.sh, line 136:  Called src_compile
 [31;01m*[0m   environment, line 3786:  Called die
 [31;01m*[0m The specific snippet of code:
 [31;01m*[0m       RUST_BACKTRACE=1 "${EPYTHON}" ./x.py build -vv --config="${S}"/config.toml -j$(makeopts_jobs) || die
 [31;01m*[0m 
 [31;01m*[0m If you need support, post the output of `emerge --info '=dev-lang/rust-1.69.0-r1::gentoo'`,
 [31;01m*[0m the complete build log and the output of `emerge -pqv '=dev-lang/rust-1.69.0-r1::gentoo'`.
 [31;01m*[0m The complete build log is located at '/var/tmp/portage/dev-lang/rust-1.69.0-r1/temp/build.log'.
 [31;01m*[0m The ebuild environment file is located at '/var/tmp/portage/dev-lang/rust-1.69.0-r1/temp/environment'.
 [31;01m*[0m Working directory: '/var/tmp/portage/dev-lang/rust-1.69.0-r1/work/rustc-1.69.0-src'
 [31;01m*[0m S: '/var/tmp/portage/dev-lang/rust-1.69.0-r1/work/rustc-1.69.0-src'
Comment 1 cilly 2023-06-03 18:12:37 UTC
Created attachment 863142 [details]
eclass debug log
Comment 2 cilly 2023-06-03 18:13:35 UTC
Created attachment 863143 [details]
emerge --info
Comment 3 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-06-04 06:21:06 UTC
I guess pax is relevant here.
Comment 4 cilly 2023-06-04 11:47:27 UTC
(In reply to Sam James from comment #3)
> I guess pax is relevant here.

Likely, but 1.66.1 builds just fine. I can't see some relevant changes in the diff of the ebuilds between the two versions. May be, this is an upstream matter.

grsec: denied RWX mprotect of <stack> by /var/tmp/portage/dev-lang/rust-1.69.0-r1/work/rust-stage0/bin/rustc[rustc:31400] uid/euid:0/0 gid/egid:0/0, parent /var/
tmp/portage/dev-lang/rust-1.69.0-r1/work/rust-stage0/bin/cargo[cargo:31399] uid/euid:0/0 gid/egid:0/0

On the other hand, the libLLVM-15-rust-1.68.2-stable.so does not match the rust-1.69.0-r1 version, not sure, if this might be a problem, too.
Comment 5 Guillaume Ceccarelli 2023-06-07 18:36:59 UTC
I just hit a similar issue on a PaX-enabled machine. I think the bundled rust compiler binaries need to be pax-marked to disable mprotect; i.e 'pax-mark -m "${WORKDIR}/rust-stage0/bin/rustc"' in this case.

Similarly, rust and rust-bin packages likely need to "pax-mark -m" the rust compiler binaries they build and install. I don't think it's being done today.
Comment 6 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-06-07 18:46:39 UTC
Can someone who uses PaX please give a patch to the ebuild using the pax-utils eclass? Thanks.
Comment 7 genBTC 2023-07-09 22:54:07 UTC
This bug _seems_ related to another bug I had on my SELINUX setup, since it has { execstack } (and execmem) memory RWX protections, comparable to a PAX setup.

the last discussion i had in #gentoo-hardened about it was this:

<concord__> sam_: not sure if anyone else has seen this, but lately ive been seeing this with ebuilds that have rust components and selinux:
<concord__> rustc: error while loading shared libraries: libLLVM-15-rust-1.66.0-stable.so: cannot enable executable stack as shared object requires: Permission denied
<concord__> thats with rust-bin, not sure if it affects the non-bin yet
<sam_> saw someone else mention that they started to see exec. sections warnings (genr8eofl maybe?)
<genr8eofl>  yeah I got that. I was unhappy with the rust-bin and recompiled rust and it was gone
<genr8eofl> I was under the impression it was due to how they compiled the bin, i heard rumors of something with "BOLT" stripping the .gnu.stack section off but I couldnt be sure if that was correct
<genr8eofl> I tried to put the .gnu.stack section back into the rust-bin binary but I was unsuccessful 
<genr8eofl> I dont really get it so. thats my only information.
<genr8eofl> granting { execstack } is not the right way to fix it.
<concord__> genr8eofl: agreed granting execstack is likely dangerous here. glad to hear you were able to work around it that way
<concord__> installing normal rust that is
<sam_> obviously not the right way to fix it :p
<sam_> can someone file a bug first off
<perfinion> oh man bolt strips off .gnu.stack? rude...

That issue pertained to -z noexecstack and .gnu.stack being stripped off.
Now I think this 3rd related bug @ https://github.com/rust-lang/rust/issues/112286
because it seems to be related to the stripping, and there was a patch there to disable BOLT.

Nobody seems sure, but these sections might be being stripped out of the linker
Comment 8 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-08-10 01:02:01 UTC
This looks fixed upstream per https://github.com/rust-lang/rust/issues/105783?
Comment 9 Attila Tóth 2023-10-11 10:30:51 UTC
Your are also using grsec.
Note, that since 1.66, I maintain a modified ebuild for my own use with these changes:
@@ -6,7 +6,7 @@ EAPI=8
 PYTHON_COMPAT=( python3_{9..12} )

 inherit bash-completion-r1 check-reqs estack flag-o-matic llvm multiprocessing \
-       multilib multilib-build python-any-r1 rust-toolchain toolchain-funcs verify-sig
+       multilib multilib-build pax-utils python-any-r1 rust-toolchain toolchain-funcs verify-sig

 if [[ ${PV} = *beta* ]]; then
        betaver=${PV//*beta}
@@ -42,7 +42,7 @@ LLVM_TARGET_USEDEPS=${ALL_LLVM_TARGETS[@

 LICENSE="|| ( MIT Apache-2.0 ) BSD BSD-1 BSD-2 BSD-4"

-IUSE="big-endian clippy cpu_flags_x86_sse2 debug dist doc llvm-libunwind +lto miri nightly parallel-compiler profiler rustfmt rust-analyzer rust-src system-bootstrap system-llvm test wasm ${ALL_LLVM_TARGETS[*]}"
+IUSE="big-endian clippy cpu_flags_x86_sse2 debug dist doc llvm-libunwind +lto miri nightly parallel-compiler pax-kernel profiler rustfmt rust-analyzer rust-src system-bootstrap system-llvm test wasm ${ALL_LLVM_TARGETS[*]}"

 # Please keep the LLVM dependency block separate. Since LLVM is slotted,
 # we need to *really* make sure we're not pulling more than one slot
@@ -303,6 +303,10 @@ src_prepare() {
                        --without=rust-docs-json-preview,rust-docs --destdir="${rust_stage0_root}" --prefix=/ || die
        fi

+       if use pax-kernel ; then
+               pax-mark -Cm ${WORKDIR}/${PN}-stage0/bin/rustc || die
+       fi
+
        default
 }