Created attachment 413892 [details] My Kernel's GrSec config Hello, For some time past I use the hardened-profile with hardened-sources (actual 4.1.7-r1), hardened toolchain, Pax and some further GrSec features activated on a Xfce-Desktop. My problem is now that calibres (2.35.0) "ebook-viewer" and "ebook-editor" crashes with the following output ================================================================================ 1 0x37a2be21889 /usr/lib64/libQt5WebKit.so.5(WTFCrash+0x39) [0x37a2be21889] 2 0x37a2be6f9d8 /usr/lib64/libQt5WebKit.so.5(_ZN3WTF11OSAllocator6commitEPvmbb+0x58) [0x37a2be6f9d8] 3 0x37a2be5007d /usr/lib64/libQt5WebKit.so.5(+0x1ddf07d) [0x37a2be5007d] 4 0x37a2be501b0 /usr/lib64/libQt5WebKit.so.5(_ZN3WTF13MetaAllocator8allocateEmPv+0xc0) [0x37a2be501b0] 5 0x37a2bc333c9 /usr/lib64/libQt5WebKit.so.5(+0x1bc23c9) [0x37a2bc333c9] 6 0x37a2babdaf6 /usr/lib64/libQt5WebKit.so.5(+0x1a4caf6) [0x37a2babdaf6] 7 0x37a2bc873ec /usr/lib64/libQt5WebKit.so.5(+0x1c163ec) [0x37a2bc873ec] 8 0x37a2bc87715 /usr/lib64/libQt5WebKit.so.5(+0x1c16715) [0x37a2bc87715] 9 0x37a2bc7d16b /usr/lib64/libQt5WebKit.so.5(+0x1c0c16b) [0x37a2bc7d16b] 10 0x37a2bc7d6af /usr/lib64/libQt5WebKit.so.5(+0x1c0c6af) [0x37a2bc7d6af] 11 0x37a2bd78e86 /usr/lib64/libQt5WebKit.so.5(_ZN3JSC10JSFunction6createEPNS_9ExecStateEPNS_14JSGlobalObjectEiRKN3WTF6StringEPFlS2_ENS_9IntrinsicESA_+0x56) [0x37a2bd78e86] 12 0x37a2bd60108 /usr/lib64/libQt5WebKit.so.5(+0x1cef108) [0x37a2bd60108] 13 0x37a2bd867ea /usr/lib64/libQt5WebKit.so.5(+0x1d157ea) [0x37a2bd867ea] 14 0x37a2bd8a974 /usr/lib64/libQt5WebKit.so.5(_ZN3JSC14JSGlobalObject4initEPNS_8JSObjectE+0x84) [0x37a2bd8a974] 15 0x37a2b9c9964 /usr/lib64/libQt5WebKit.so.5(+0x1958964) [0x37a2b9c9964] 16 0x37a2b9ecb46 /usr/lib64/libQt5WebKit.so.5(+0x197bb46) [0x37a2b9ecb46] 17 0x37a2b9eccad /usr/lib64/libQt5WebKit.so.5(+0x197bcad) [0x37a2b9eccad] 18 0x37a2a766225 /usr/lib64/libQt5WebKit.so.5(+0x6f5225) [0x37a2a766225] 19 0x37a2a766b60 /usr/lib64/libQt5WebKit.so.5(+0x6f5b60) [0x37a2a766b60] 20 0x37a2b9c9e07 /usr/lib64/libQt5WebKit.so.5(+0x1958e07) [0x37a2b9c9e07] 21 0x37a2a534879 /usr/lib64/libQt5WebKit.so.5(_ZN16QWebFrameAdapter27addToJavaScriptWindowObjectERK7QStringP7QObjectNS_14ValueOwnershipE+0x89) [0x37a2a534879] 22 0x37a24ef8617 /usr/lib64/python2.7/site-packages/PyQt5/QtWebKitWidgets.so(+0x29617) [0x37a24ef8617] 23 0x37a3c1f0502 /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x5282) [0x37a3c1f0502] 24 0x37a3c1f1b88 /usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x818) [0x37a3c1f1b88] 25 0x37a3c1f016d /usr/lib64/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x4eed) [0x37a3c1f016d] 26 0x37a3c1f1b88 /usr/lib64/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x818) [0x37a3c1f1b88] 27 0x37a3c16b66e /usr/lib64/libpython2.7.so.1.0(+0x7b66e) [0x37a3c16b66e] 28 0x37a3c13d366 /usr/lib64/libpython2.7.so.1.0(PyObject_Call+0x66) [0x37a3c13d366] 29 0x37a3c14fe2d /usr/lib64/libpython2.7.so.1.0(+0x5fe2d) [0x37a3c14fe2d] 30 0x37a3c13d366 /usr/lib64/libpython2.7.so.1.0(PyObject_Call+0x66) [0x37a3c13d366] 31 0x37a3c1a82da /usr/lib64/libpython2.7.so.1.0(+0xb82da) [0x37a3c1a82da] Speicherzugriffsfehler ================================================================================ (Speicherzugriffsfehler means segfault) It seems that the problem is not related to calibre itsself but to python 2.7 (2.7.10 in use) and its collaboration with Pax during libffi and/or cffi. Namely I found this after some googeling "https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787016" To make it short here it is claimed that "that's because with current libffi python want's an executable stack, which fails under grsec kernels." I use libffi 3.0.13-r1 and cffi-1.2.1 Best regards
What pax flags is set on the active python? Check you kernel Grsec/Pax logs them should have more info. Lib libffi and cffi is allready fixed and it use CONFIG_PAX_EMUTRAMP if the bins is correctly setup. Check so you don't have any jit enable on any libs that calibre use. emerge --info
Thanks for your reply! #paxctl-ng -v /usr/bin/python2.7 /usr/bin/python2.7: PT_PAX : -e--- XATTR_PAX : -E--- #paxctl-ng -v /usr/bin/python3.4 /usr/bin/python3.4: PT_PAX : -e--- XATTR_PAX : -E--- #eselect python list Available Python interpreters: [1] python2.7 [2] python3.4 * #dmesg (Only the line related to the problem) [ 3925.641370] ebook-viewer[2747]: segfault at bbadbeef ip 000003c688d6988e sp 000003cd50f82e00 error 6 in libQt5WebKit.so.5.4.2[3c686fb9000+2427000] My make.conf settings for Pax PAX_MARKINGS="XT" PAXUSE="ptpax xattr xtpax" My make.conf settings for Python PYTHON_TARGETS="python3_4 python2_7" PYTHON_SINGLE_TARGET="python2_7" USE_PYTHON="3.4 2.7"emerge After installation of the Pax-Kernel and with these make .conf settings I made a "emerge -av --emptytree world". All Pax settings are "default" which means I does not change any pax-flags at myself.
Created attachment 414206 [details] Output of emerge --info calibre
Can you try running `python -c 'import ctypes'` and see if it segfaults. All you rsetting seem right, however, I don't understand PAXUSE="ptpax xattr xtpax" Those flags should just be part of your USE flags.
Sorry I forgot to say: I split my USE-Flags into multiple subcategories. The Pax one I called PAXUSE, I forgot to say that. At the end I set them together with USE="... ${PAXUSE} ..." Just for a better overview in make.conf. So "ptpax xattr xtpax" are part of USE. However, `python -c 'import ctypes'` produces no segfault. Thanks for your answer.
Hi. I have issue with python-2.7/pax/grsec, but not calibre. My segfaults with pyicq-t. Thank Comment 4 for direction, I found with: python2 -v pyicq-t imports and track down my issue to: $ python2 -c "import cryptography.hazmat.bindings.openssl.binding" Segmentation fault [ 3203.233384] python2[2070]: segfault at 0 ip 5225b785 sp 5c97ac50 error 6 in libffi.so.6.0.1[52257000+6000] [ 3203.233403] grsec: Segmentation fault occurred at (nil) in /usr/bin/python2.7[python2:2070] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[bash:1520] uid/euid:0/0 gid/egid:0/0
(In reply to Maxim Britov from comment #6) > Hi. I have issue with python-2.7/pax/grsec, but not calibre. > My segfaults with pyicq-t. > > Thank Comment 4 for direction, I found with: python2 -v pyicq-t > imports and track down my issue to: > > $ python2 -c "import cryptography.hazmat.bindings.openssl.binding" > Segmentation fault > > [ 3203.233384] python2[2070]: segfault at 0 ip 5225b785 sp 5c97ac50 error 6 > in libffi.so.6.0.1[52257000+6000] > [ 3203.233403] grsec: Segmentation fault occurred at (nil) in > /usr/bin/python2.7[python2:2070] uid/euid:0/0 gid/egid:0/0, parent > /bin/bash[bash:1520] uid/euid:0/0 gid/egid:0/0 Check that you have CONFIG_PAX_EMUTRAMP set in the kernel config.
(In reply to Gerold Schellstede from comment #5) > Sorry I forgot to say: I split my USE-Flags into multiple subcategories. The > Pax one I called PAXUSE, I forgot to say that. At the end I set them > together with > USE="... ${PAXUSE} ..." > Just for a better overview in make.conf. So "ptpax xattr xtpax" are part of > USE. > > However, `python -c 'import ctypes'` produces no segfault. > > Thanks for your answer. if you change the paxmarks to m do it still segfault?
(In reply to Magnus Granberg from comment #7) > > Check that you have CONFIG_PAX_EMUTRAMP set in the kernel config. The original reporter (Gerold) attached his kernel config in comment #0 ad he does have PAX_EMUTRAMP on. So something else is going on. I'm not sure about Maxim.
(In reply to Anthony Basile from comment #9) > (In reply to Magnus Granberg from comment #7) > > > > Check that you have CONFIG_PAX_EMUTRAMP set in the kernel config. > > The original reporter (Gerold) attached his kernel config in comment #0 ad > he does have PAX_EMUTRAMP on. So something else is going on. I'm not sure > about Maxim. Two reporter and two diffrents errors.
(In reply to Magnus Granberg from > Two reporter and two diffrents errors. Sorry, but wrong title in this issue. imho (In reply to Magnus Granberg from comment #7) > (In reply to Maxim Britov from comment #6) > Check that you have CONFIG_PAX_EMUTRAMP set in the kernel config. Yes. EMUTRAMP unset. But I report issue because it works for longtime. My kernel from 27 Sep and issue from reboot on 6 Oct. I found source of my problem: =dev-python/cryptography-0.9.3 fine =dev-python/cryptography-1.0.2 segfaults Sorry for noise here. Should it report to upstream or EMUTRAMP=y only or 1.0 nd above?
(In reply to Maxim Britov from comment #11) > (In reply to Magnus Granberg from > > Two reporter and two diffrents errors. > > Sorry, but wrong title in this issue. imho > > (In reply to Magnus Granberg from comment #7) > > (In reply to Maxim Britov from comment #6) > > Check that you have CONFIG_PAX_EMUTRAMP set in the kernel config. > > Yes. EMUTRAMP unset. But I report issue because it works for longtime. > My kernel from 27 Sep and issue from reboot on 6 Oct. > > I found source of my problem: > =dev-python/cryptography-0.9.3 fine > =dev-python/cryptography-1.0.2 segfaults > > Sorry for noise here. Should it report to upstream > or EMUTRAMP=y only or 1.0 nd above? Anything that use the libffi or cffi need to have EMUTRAMP on.
(In reply to Magnus Granberg from comment #8) > (In reply to Gerold Schellstede from comment #5) > > Sorry I forgot to say: I split my USE-Flags into multiple subcategories. The > > Pax one I called PAXUSE, I forgot to say that. At the end I set them > > together with > > USE="... ${PAXUSE} ..." > > Just for a better overview in make.conf. So "ptpax xattr xtpax" are part of > > USE. > > > > However, `python -c 'import ctypes'` produces no segfault. > > > > Thanks for your answer. > if you change the paxmarks to m do it still segfault? Indeed, I changed /usr/bin/python2.7 from "-E---" to "-Em--" the segfault is gone and the program works
Short request, shouldn't the Pax flags be set on the ELF-binaries of calibres ebook-viewer etc. instead of python 2.7 or does python 2.7 needs this flags in principle? Thanks for the help
(In reply to Gerold Schellstede from comment #14) > Short request, > > shouldn't the Pax flags be set on the ELF-binaries of calibres ebook-viewer > etc. instead of python 2.7 or does python 2.7 needs this flags in principle? > > Thanks for the help should be on the elf binaries can you test that?
I thought as much! But unfortunately I do not know where the ELF-binaries of calibre, especcially of the ebook-viewer, are located. So if you can tell me where they are, I will try it immediately. Many Thanks!
(In reply to Gerold Schellstede from comment #16) > I thought as much! But unfortunately I do not know where the ELF-binaries of > calibre, especcially of the ebook-viewer, are located. > > So if you can tell me where they are, I will try it immediately. > > Many Thanks! Looks like calibre is alot of python code. The main prob is in qt webkit looks like it use jit in the js code
(In reply to Magnus Granberg from comment #17) > (In reply to Gerold Schellstede from comment #16) > > I thought as much! But unfortunately I do not know where the ELF-binaries of > > calibre, especcially of the ebook-viewer, are located. > > > > So if you can tell me where they are, I will try it immediately. > > > > Many Thanks! > > Looks like calibre is alot of python code. > The main prob is in qt webkit looks like it use jit in the js > code I tested the following settings while setting /usr/bin/python2.7 to default (-E---). 1) Set "/usr/lib64/libpython3.4.so.1.0" to "perms" and "/usr/lib64/libpython3.4.so.1.0" to "perms" --> Does not work 2) Setting them both to "--m--" --> Does not work 3) Setting them both to "-Em--" --> Does not work 4) I tested the three settings above for each of "/usr/lib64/libpython3.4.so.1.0" and "/usr/lib64/libpython3.4.so.1.0" separately while set the other one to its default settings. --> Does not work Going back to (-Em--) "/usr/bin/python2.7" resolves the problem again?!?
This is at the third report in the last month or so from a user with EMUTRAMP disabled hitting PaX faults for python-related stuff. Did something change? Can we do anything to prevent these duplicate bug reports?
Sorry, this was meant for bug 564940, but the question still stands.
Created attachment 416198 [details, diff] disable jit This patch should disable jit on qtwebkit can some one test it?
(In reply to Mike Gilbert from comment #20) > Sorry, this was meant for bug 564940, but the question still stands. Nothing changed that would be triggering this bug. 4475_emutramp_default_on.patch is present in all hardened-sources patchsets and it turns off EMUTRAMP by default. The user has to manually turn off this option to hit this bug. I have no explanation at this time why 3 such bugs appeared in the last month.
(In reply to Anthony Basile from comment #22) > (In reply to Mike Gilbert from comment #20) > > Sorry, this was meant for bug 564940, but the question still stands. > > Nothing changed that would be triggering this bug. > 4475_emutramp_default_on.patch is present in all hardened-sources patchsets > and it turns off EMUTRAMP by default. The user has to manually turn off > this option to hit this bug. > > I have no explanation at this time why 3 such bugs appeared in the last > month. I am just asking to be sure what you mean. I enabled EMUTRAMP in the kernel, but the outcome is that it is deactivated by default?! So I have to enable it manually?! But then I do not understand that python 2.7 does not work with -E--- so I have to set -Em-- to make it work??? What is the relation to the disable jit patch? If someone explains to which ebuild (with version) the patch should be applied I will test it. Best regards
(In reply to Gerold Schellstede from comment #23) > (In reply to Anthony Basile from comment #22) > > (In reply to Mike Gilbert from comment #20) > > > Sorry, this was meant for bug 564940, but the question still stands. > > > > Nothing changed that would be triggering this bug. > > 4475_emutramp_default_on.patch is present in all hardened-sources patchsets > > and it turns off EMUTRAMP by default. The user has to manually turn off > > this option to hit this bug. > > > > I have no explanation at this time why 3 such bugs appeared in the last > > month. > > I am just asking to be sure what you mean. I enabled EMUTRAMP in the kernel, > but the outcome is that it is deactivated by default?! So I have to enable > it manually?! > > But then I do not understand that python 2.7 does not work with -E--- so I > have to set -Em-- to make it work??? Python works well with E but calibre is importing qtwebkit that use jit and the only way around it to run python with m or disable jit in qtwebkit as the patch do. > > What is the relation to the disable jit patch? > > If someone explains to which ebuild (with version) the patch should be > applied I will test it. > > Best regards the patch is for qtwebkit 5.X
(In reply to Magnus Granberg from comment #24) > (In reply to Gerold Schellstede from comment #23) > > (In reply to Anthony Basile from comment #22) > > > (In reply to Mike Gilbert from comment #20) > > > > Sorry, this was meant for bug 564940, but the question still stands. > > > > > > Nothing changed that would be triggering this bug. > > > 4475_emutramp_default_on.patch is present in all hardened-sources patchsets > > > and it turns off EMUTRAMP by default. The user has to manually turn off > > > this option to hit this bug. > > > > > > I have no explanation at this time why 3 such bugs appeared in the last > > > month. > > > > I am just asking to be sure what you mean. I enabled EMUTRAMP in the kernel, > > but the outcome is that it is deactivated by default?! So I have to enable > > it manually?! > > > > But then I do not understand that python 2.7 does not work with -E--- so I > > have to set -Em-- to make it work??? > Python works well with E but calibre is importing qtwebkit that use jit and > the only way around it to run python with m or disable jit in > qtwebkit as the patch do. > > > > What is the relation to the disable jit patch? > > > > If someone explains to which ebuild (with version) the patch should be > > applied I will test it. > > > > Best regards > the patch is for qtwebkit 5.X Thanks really a lot. The patch does the trick. Calibre works now with all its features using python's "out the box pax-flags". The outcome of the problem seems to be that a jit-flag is needed for all future versions of qtwebkit 5.x. Should someone file a bug-report for qtwebkit5.x about this need? Best Regards
*** Bug 566914 has been marked as a duplicate of this bug. ***
*** Bug 569108 has been marked as a duplicate of this bug. ***
Thanks everyone, fixed in git. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=09ef50e18b133b1fa59ef57a384933d7dde4e69c
