Created attachment 510418 [details, diff] paxmark failing tests sys-libs/compiler-rt-4.0.1 fails the two tests * test/builtins/Unit/enable_execute_stack_test and * test/builtins/Unit/clear_cache_test due to PAX feature MPROTECT. dmesg reads grsec: denied RWX mprotect of <stack> by /var/tmp/portage/sys-libs/compiler-rt-4.0.1/work/compiler-rt-4.0.1.src/test/builtins/Unit/enable_execute_stack_test[enable_execute_:16130] uid/euid:250/250 gid/egid:250/250, parent /usr/bin/gmake[make:15431] uid/euid:250/250 gid/egid:250/250 PAX: execution attempt in: <stack>, ff831000-ff856000 3fffffda000 grsec: denied RWX mprotect of /var/tmp/portage/sys-libs/compiler-rt-4.0.1/work/compiler-rt-4.0.1.src/test/builtins/Unit/clear_cache_test by /var/tmp/portage/sys-libs/compiler-rt-4.0.1/work/compiler-rt-4.0.1.src/test/builtins/Unit/clear_cache_test[clear_cache_tes:16138] uid/euid:250/250 gid/egid:250/250, parent /usr/bin/gmake[make:15431] uid/euid:250/250 gid/egid:250/250 Attached a patch for the 4.0.1 ebuild to call paxmark.sh on the executable before running. It modifies the Makefile generated by the ebuild to include that paxmark.sh call. Note that the tests for 5.0.1 are handled by lit/CMake and not by an ebuild generated Makefile so another solution has to be found. PS: Yes, I know that there is no PAX hardened kernel in the official tree anymore. It would nevertheless be nice if you paxmark the above tests. Thanks!
Created attachment 515350 [details, diff] compiler-rt-5.0.1-PAX-mark-test-suite.patch Updated patch for compiler-rt-5.0.1. Note that running the tests is now done by the build system (more precisely by lit) and not by the ebuild any more.
I will not carry a patch for this locally. Please take it to LLVM upstream. Besides, I don't undertand why you're using some fancy tooling instead of regular paxctl.
> I will not carry a patch for this locally. Please take it to LLVM upstream. Ok, thanks for the reply. > Besides, I don't undertand why you're using some fancy tooling instead of regular paxctl. That's simple: because all the ebuild use it if they need to deal with pax markings and cannot use the eclass pax-utils (e.g. because the call is done in a Makefile). None if them uses your suggested paxctl. I'm sorry if that's not the modern approach but documentation is scare about this subject so suggestions are welcome.
