On a PAX hardened kernel some tests of the Mesa test suite fail. The tests in question are all five tests in src/gallium/drivers/llvmpipe/, namely lp_test_arit, lp_test_blend, lp_test_conv, lp_test_format, and lp_test_printf. The violation reported is grsec: denied RWX mprotect of <anonymous mapping> by /var/tmp/portage/media-libs/mesa-18.2.4/work/mesa-18.2.4-abi_x86_64.amd64/src/gallium/drivers/llvmpipe/lp_test_format[lp_test_format:13928] uid/euid:250/250 gid/egid:250/250, parent /usr/bin/python3.6m[python3.6:13203] uid/euid:250/250 gid/egid:250/250 and similar for the other tests. One way to solve this issue pax-mark the test executables with NOMPROTECT ("m" in paxctl, et al), e.g. in multilib_src_test(): # The following tests fail on PAX hardened systems. # PAX-mark them to not enforce MPROTECT. for t in lp_test_arit lp_test_blend lp_test_conv lp_test_format lp_test_printf; do pax-mark m "${BUILD_DIR}/src/gallium/drivers/llvmpipe/${t}" done (pax-mark is a helper defined in the pax-utils eclass already inherited by the mesa-ebuild) Attached a patch for the mesa-18.2.4 ebuild inserting the above lines. It would be nice if that gets fixed although running a PAX kernel is kind of unusually nowadays. Thanks.
Created attachment 554056 [details, diff] PAX mark the test suite with NOMPROTECT
Those tests all fail, presumably, because they JIT compile code (using LLVMpipe). Isn't anything using LLVMpipe going to fail in the same way? Seems like we would need to disable llvmpipe on PaX systems, which I suppose are going the way of the dodo. I'd rather not do that...
> Those tests all fail, presumably, because they JIT compile code (using > LLVMpipe). Isn't anything using LLVMpipe going to fail in the same way? > > Seems like we would need to disable llvmpipe on PaX systems, which I suppose > are going the way of the dodo. I'd rather not do that... I also would not disable llvmpipe that would be overreacting. I think it is also the responsibility of the using code/package/... to make sure its build executable has the appropriate marking (in this case disable MPROTECT). The tests show that this works: only the test executable needs a marking. Please note that the old ebuild (mesa-18.1.9) did PaX-mark the tests [0]. So these failures are a regression. > ... PaX systems, which I suppose are going the way of the dodo. I agree with that but maybe some similar protection gets incorporated at some day (some parts of grsecurity are finding their way upstream already today). But until then I understand that you would not put too much effort in being PaX compatible. Nevertheless, I would, if the cost is negligible, maintain the current PaX support without actively removing it, which in this case would be not deleting the code which PaX-marks the test suite. So I'd like to kindly ask you to reconsider your decision. [0] https://cgit.gentoo.org/repo/gentoo.git/tree/media-libs/mesa/mesa-18.1.9.ebuild?id=d6dc5e9bd50fab202cda8ab12b0ed034e7a99dc4#n444
(In reply to Hermila Hoover from comment #3) > > Those tests all fail, presumably, because they JIT compile code (using > > LLVMpipe). Isn't anything using LLVMpipe going to fail in the same way? > > > > Seems like we would need to disable llvmpipe on PaX systems, which I suppose > > are going the way of the dodo. I'd rather not do that... > > I also would not disable llvmpipe that would be overreacting. I think it is > also the responsibility of the using code/package/... to make sure its build > executable has the appropriate marking (in this case disable MPROTECT). The > tests show that this works: only the test executable needs a marking. Right, but my question is whether these tests failing indicates that the installed package will also fail. These tests fail because they JIT compile code and execute it. That's what LLVMpipe does. Won't anything using LLVMpipe fail similarly? If that's the case, then the tests failing is the correct thing to do and the question becomes... what do we do about LLVMpipe on PaX systems?
(In reply to Matt Turner from comment #4) > Right, but my question is whether these tests failing indicates that the > installed package will also fail. These tests fail because they JIT compile > code and execute it. That's what LLVMpipe does. Won't anything using LLVMpipe > fail similarly? > > If that's the case, then the tests failing is the correct thing to do and the > question becomes... what do we do about LLVMpipe on PaX systems? I patched the ebuild as mentioned above and so far I had no problems with mesa and PaX. Also users of older versions of the mesa ebuild (<= 18.1.9) did not seem to have any problem with PaX and llvmpipe. Actually the issue with PaX and llvmpipe is quite old: Here is a reference to the bug #506412 at that time [0]. [0] https://bugs.gentoo.org/show_bug.cgi?id=506412
Did you actually try to use llvmpipe? What do you have VIDEO_CARDS set to? What does LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep -A3 'OpenGL vendor string' say? Does LIBGL_ALWAYS_SOFTWARE=1 glxgears work? (I suspect that will JIT compile and execute some code using LLVM but I'm not 100% sure without trying myself).
(In reply to Matt Turner from comment #6) > Did you actually try to use llvmpipe? What do you have VIDEO_CARDS set to? I used my normal X server setup as I don't know how to trigger the use of llvmpipe neither do I know what might use it. My video cards are set to VIDEO_CARDS="i965 intel" (In reply to Matt Turner from comment #6) > What does > > LIBGL_ALWAYS_SOFTWARE=1 glxinfo | grep -A3 'OpenGL vendor string' > > say? It says "command not found: glxinfo" :) ... but after fixing that I get OpenGL vendor string: VMware, Inc. OpenGL renderer string: llvmpipe (LLVM 6.0, 256 bits) OpenGL core profile version string: 3.3 (Core Profile) Mesa 18.2.4 OpenGL core profile shading language version string: 3.30 So it does use llvmpipe. (In reply to Matt Turner from comment #6) > Does LIBGL_ALWAYS_SOFTWARE=1 glxgears work? (I suspect that will JIT compile > and execute some code using LLVM but I'm not 100% sure without trying myself). As you suspected it gets killed by PaX and for the record "LIBGL_ALWAYS_SOFTWARE=1 glxgears" also gets killed by PaX on older mesa versions (tested with mesa-18.1.9). For me the enlightening part above was the *environment variable* LIBGL_ALWAYS_SOFTWARE as I know begin to understand your point. I did not know about this variable and thought that the program (glxgears in this case) chooses which graphics driver/stack to use (either at compile or runtime). But the environment variable shows that in fact the user determines it and can even bypassing the program completely. So the program cannot know whether it will use llvmpipe or not. @Matt Thanks for discussing, your patience, and leading me to this insight.
You're welcome! If your VIDEO_CARDS is set to "i965 intel" then you can turn off USE=gallium and you will not build llvmpipe. I think the old situation of PaX marking the test programs was the wrong thing to do, since the tests accurately reflect the behavior of the installed binaries. Let's mark as WONTFIX and let PaX users know llvmpipe doesn't work for them.
