Summary: | dev-lang/rust-1.69.0-r1 - compile error - libLLVM-15-rust-1.68.2-stable.so: cannot enable executable stack as shared object | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | cilly <cilly> |
Component: | Current packages | Assignee: | Gentoo Rust Project <rust> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | gentoo, guillaume, navi, randy, rust |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://github.com/rust-lang/rust/issues/105783 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 911589 | ||
Attachments: |
build log
eclass debug log emerge --info |
Description
cilly
2023-06-03 18:12:01 UTC
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 } |