Fresh install on amd64 hardened system. - Currently using the toolchain provided from "Hardened Development" - Kernel is patched with latest grsecurity patch and some genpatches from trunk. I've attempted the following: - Revdep-rebuild - Re-emerged redland, soprano, rapter, clucene, strigi, sun-jdk - Upgraded redland to 1.0.9 and rapter and re-emerged the above - Upgraded sun-jdk and raptor - Toggled between -/+ sqlite, -/+ berkdb, -/+ mysql for redland on both 1.0.8 and 1.0.9 - Toggled use flags that might play a part with db backends, ie sun's derby or jce. Reproducible: Always Steps to Reproduce: 1. Tried to emerge kdebase-startkde-4.3.0 2. Or - Tried to emerge kdebase-meta-4.3.0 3. Actual Results: Please see attached build log.
Created attachment 202756 [details] emerge info
Created attachment 202758 [details] build log
(In reply to comment #0) I can confirm that bug. Apparently this is due to hardened setup: Sep 10 17:14:21 palantir kernel: onto2vocabulary[18882]: segfault at 3558e7bd5d80 ip 00003558e79c0d41 sp 000077a35accc7a0 error 7 in ld-2.9.so[3558e79ba000+1c000] Sep 10 17:14:21 palantir kernel: grsec: signal 11 sent to /usr/bin/onto2vocabularyclass[onto2vocabulary:18882] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:18881] uid/euid:0/0 gid/egid:0/0 Sep 10 17:14:21 palantir kernel: grsec: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /usr/bin/onto2vocabularyclass[onto2vocabulary:18882] uid/euid:0/0 gid/egid:0/0, parent /bin/bash[sh:18881] uid/euid:0/0 gid/egid:0/0
Seems i mistook result for the reason :) grsec was just reporting segfault. The SEGFAULT happens in onto2vocabluaryclass belonging to soprano. Downgrading soprano from 2.3.0-r1 to 2.3.0 (including dependencies) allows for the nepomuk to compile (at least for me)
onto2vocabulary class implicitly tries to load libjvm.so from sun jdk. The process gets killed in dl-load.c:1399 (if using sys-libs/glibc-2.10.1) when trying to alter the stack protection. if (__builtin_expect (p + s <= relro_end, 1)) 1396 { 1397 /* The variable lies in the region protected by RELRO. */ 1398 __mprotect ((void *) p, s, PROT_READ|PROT_WRITE); 1399 __stack_prot |= PROT_READ|PROT_WRITE|PROT_EXEC; 1400 __mprotect ((void *) p, s, PROT_READ); 1401 } 1402 else 1403 __stack_prot |= PROT_READ|PROT_WRITE|PROT_EXEC; The principal problem regarding java vs pax is described here: http://forums.grsecurity.net/viewtopic.php?f=3&t=60&start=0&sid=8b9298f486fee7d98ef57f6d1467105f After dev-libs/soprano-2.3.0 vanished from distribution in the meantime, another workaround is running "paxctl -m /usr/bin/onto2vocabularyclass" after having emerged dev-libs/soprano. Maybe the soprano ebuild could set this automatically, as java principally relies on run-time generated code? A gdb backtrace follows: Core was generated by `onto2vocabularyclass --name NIE --encoding trig --namespace Nepomuk::Vocabulary'. Program terminated with signal 11, Segmentation fault. [New process 16751] #0 _dl_map_object_from_fd (name=0x326054048858 "libjvm.so", fd=7, fbp=<value optimized out>, realname=0x85624764490 "/opt/sun-jdk-1.6.0.16/jre/lib/amd64/server/libjvm.so", loader=<value optimized out>, l_type=<value optimized out>, mode=-2147483648, stack_endp=0x719d1a6273f8, nsid=0) at dl-load.c:1399 1399 __stack_prot |= PROT_READ|PROT_WRITE|PROT_EXEC; (gdb) bt f #0 _dl_map_object_from_fd (name=0x326054048858 "libjvm.so", fd=7, fbp=<value optimized out>, realname=0x85624764490 "/opt/sun-jdk-1.6.0.16/jre/lib/amd64/server/libjvm.so", loader=<value optimized out>, l_type=<value optimized out>, mode=-2147483648, stack_endp=0x719d1a6273f8, nsid=0) at dl-load.c:1399 #1 0x00003260512bfb3d in _dl_map_object (loader=0x85624724080, name=0x326054048858 "libjvm.so", preloaded=0, type=2, trace_mode=0, mode=-2147483648, nsid=0) at dl-load.c:2235 #2 0x00003260512c4bbd in openaux (a=<value optimized out>) at dl-deps.c:65 #3 0x00003260512c55a6 in _dl_catch_error (objname=0x719d1a627708, errstring=0x719d1a627710, mallocedp=0x719d1a62771f, operate=0x3260512c4b80 <openaux>, args=0x719d1a6276e0) at dl-error.c:178 #4 0x00003260512c3c47 in _dl_map_object_deps (map=0x85624724080, preloads=<value optimized out>, npreloads=<value optimized out>, trace_mode=0, open_mode=-2147483648) at dl-deps.c:248 #5 0x00003260512c9add in dl_open_worker (a=<value optimized out>) at dl-open.c:326 #6 0x00003260512c55a6 in _dl_catch_error (objname=0x719d1a627980, errstring=0x719d1a627978, mallocedp=0x719d1a62798f, operate=0x3260512c9950 <dl_open_worker>, args=0x719d1a627930) at dl-error.c:178 #7 0x00003260512c942b in _dl_open (file=0x8562478cd88 "/usr/lib64/soprano/libsoprano_sesame2backend.so", mode=-2147483647, caller_dlopen=0x3260518f7782, nsid=-2, argc=9, argv=0x719d1a628e08, env=0x719d1a628e58) at dl-open.c:616 #8 0x0000326053219f9b in dlopen_doit (a=<value optimized out>) at dlopen.c:67 #9 0x00003260512c55a6 in _dl_catch_error (objname=0x8562471cca0, errstring=0x8562471cca8, mallocedp=0x8562471cc98, operate=0x326053219f30 <dlopen_doit>, args=0x719d1a627b50) at dl-error.c:178 #10 0x000032605321a33c in _dlerror_run (operate=0x326053219f30 <dlopen_doit>, args=0x719d1a627b50) at dlerror.c:164 #11 0x0000326053219f01 in __dlopen (file=<value optimized out>, mode=<value optimized out>) at dlopen.c:88 #12 0x00003260518f7782 in QLibraryPrivate::load_sys (this=0x8562472bc80) at plugin/qlibrary_unix.cpp:186 #13 0x00003260518f37b5 in QLibraryPrivate::loadPlugin (this=0x3260514d4000) at plugin/qlibrary.cpp:494 #14 0x00003260518ee9d9 in QPluginLoader::instance (this=0x3260514d4000) at plugin/qpluginloader.cpp:183 #15 0x0000326051538189 in Soprano::PluginStub::plugin (this=0x8562472a498) at /usr/src/debug/dev-libs/soprano-2.3.1/soprano-2.3.1/soprano/pluginstub.cpp:94 #16 0x00003260515371ff in Soprano::PluginManager::discoverBackendByName (this=0x8562471c200, name=@0x719d1a628ab0) at /usr/src/debug/dev-libs/soprano-2.3.1/soprano-2.3.1/soprano/pluginmanager.cpp:140 #17 0x00000856244ff432 in main (argc=9, argv=<value optimized out>) at /usr/src/debug/dev-libs/soprano-2.3.1/soprano-2.3.1/tools/onto2vocabularyclass.cpp:239 Current language: auto; currently c
Found another bit of closely related information: http://archives.gentoo.org/gentoo-hardened/msg_2c7088a794ebbcb5cf79343004ad9f6b.xml. As you can see from the backtrace info above, the program crashed in dl-load.c within the RELRO "fix" the paxteam points to: http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/elf/dl-load.c.diff?r1=1.270&r2=1.271&cvsroot=glibc&f=h I wonder why this longstanding libc bug could not be fixed at least within hardened?
*** Bug 290511 has been marked as a duplicate of this bug. ***
*** Bug 290514 has been marked as a duplicate of this bug. ***
What's the status here with recent KDE versions (4.3.5, 4.4.2)?
No reply for two months.
For me seems to have solved :D