ponky
n00b
Joined: 26 Sep 2013
Posts: 8
|
 Posted: Tue Dec 17, 2013 11:55 am Post subject: Hardened dom0 & libgcc_s_so.1 segfaults in dmesg? |
 |
|
I'm experiencing libgcc segfaults when starting/halting a hardened domU PV (dom0 is also hardened) using xl tools. This doesn't
affect the domU itself, so it's not really a problem but I dont like those dirty messages in dmesg  .
I was chatting with a more experienced xen user via irc and according to him this is caused by PaX.
| Quote: | Linux xen 3.11.9-hardened-xen #1 SMP Mon Dec 2 13:42:33 EET 2013 x86_64 Intel(R) Xeon(R) CPU E3-1230 v3 @ 3.30GHz GenuineIntel GNU/Linux
|
| Quote: | | [327759.434452] xl[3219]: segfault at 7fed48a0def0 ip 00007fed462b6724 sp 00007fed48a0def0 error 6 in libgcc_s.so.1[7fed462a8000+16000] |
Running xl -c in gdb:
| Code: | #0 0x00007ffff589d724 in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1
#1 0x00007ffff589e17f in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1
#2 0x00007ffff589e505 in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1
#3 0x00007ffff589f176 in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1
#4 0x00007ffff589f4fc in _Unwind_ForcedUnwind () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/libgcc_s.so.1
#5 0x00007ffff73205c0 in __pthread_unwind () from /lib64/libpthread.so.0
#6 0x00007ffff731881b in sigcancel_handler () from /lib64/libpthread.so.0
#7 <signal handler called>
#8 0x00007ffff7320c9d in read () from /lib64/libpthread.so.0
#9 0x00007ffff6b2faf3 in ?? () from /usr/lib64/libxenstore.so.3.0
#10 0x00007ffff6b2fc34 in ?? () from /usr/lib64/libxenstore.so.3.0
#11 0x00007ffff6b305b6 in ?? () from /usr/lib64/libxenstore.so.3.0
#12 0x00007ffff7319f3a in start_thread () from /lib64/libpthread.so.0
#13 0x00007ffff70540bd in clone () from /lib64/libc.so.6 |
Here's the crash point:
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/xenstore/xs.c;h=261b8413102578537fc5c9494ff818fdbb2e094c;hb=HEAD#l1143
| Code: | 12:22:35 xx - it's dying at the first read_all call, not the second
12:23:05 xx - you can see 'malloc' just below the first call, if you still have that xenbits.xen.org page up...
12:24:12 xx - so, yeah. i think:
12:24:24 xx - * it's not a bug in xen, it's a bug in glibc, which is
12:24:36 xx - * probably due to hardening stuff |
|
|
Kernel & Hardware
