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'
Created attachment 863142 [details] eclass debug log
Created attachment 863143 [details] emerge --info
I guess pax is relevant here.
(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.
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.
Can someone who uses PaX please give a patch to the ebuild using the pax-utils eclass? Thanks.
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
This looks fixed upstream per https://github.com/rust-lang/rust/issues/105783?
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 }
