(2011/12/21 4:42), Dave Anderson wrote: > > > ----- Original Message ----- >> Hello Dave, >> >> I would like to send proposed patch set which can support >> PaX linux introduced at http://grsecurity.net/ over crash utility. >> >> In previous thread, you said that it is important for current implementation >> not to be increased maintenance burden. >> >> Then, I tolerably think to consider about them in my merge work with >> small modifications to current code as possible. >> But the reality is, there are several undesirable impacts which >> I made in this work. >> >> So could you please check and make a conclusion from this patch set? >> (Detail about modification are written in each patch file.) >> >> Thanks, >> Toshi > > Well, as I mentioned before, I'm not particular interested in > supporting kernel features that are not merged upstream, and > I'm afraid that I'd be starting down a slippery slope by accepting > this patch. Well, there are no happiness for upstream based users. I think so, too. Honestly speaking, I feel to be got a large nuisance called PaX and if possible, I want to extract this patch code from kernel. I am going to maintain this detour works so that I won't make fear for you because this mischief comes from product support issue which I use. > I'm curious as to whether there is a reason that their code has not > been accepted upstream? Have they attempted to get their patch merged > and it was rejected? Or have they not even tried because of technical > reasons? I'm sorry but I've never been following up this project and I still have no plan to configure this fearue itself. Thus, if crash becomes to work, there is no obstructive factor for me. If this fearue come to be recognized toward upstream, perhaps my work is also contributive for many people... > Anyway, I readily admit that I don't understand what the kernel patch > and your patch do, and I appreciate the fact that you segregated *most* > of the code with PAX() qualifiers. But I don't understand the concept > behind the new NAMESPACE_PRELOAD/NAMESPACE_RESTORE, and why it should > be imposed on the normal kernel module handling -- can't you segregate > that code as well? Because compare_syms(sp1, sp2) access sp->name if both values are equal. The sp->name is still index value which is offset from namespace heap before NAMESPACE_COMPLETE has been requested. And just because this qsort() is also able to get correct result on normal kernel module. If so, I thought integration is better. > Also, that "gap" calculation is not restricted to PAX()-only? I think init sections have "gap" caluculation. The module_alloc(mod->core_size) and module_alloc(mod->init_size) return the different vmalloc regions while all sections are calculated by module_alloc(mod->core_size) base. Init-alloc is freed immediately. This is only the problem in insmod where I haven't confirmed yet. > And note that there is no modbuf leak in verify_module(), because > all GETBUF-allocations are freed prior to the next command by > restore_sanity(). But it certainly doesn't hurt to call FREEBUF(). I did not figure out the existence of restore_sanity(). Only in this explanation, I seem FREEBUF() is no need entirely. Anyway I can understand devisal over GETBUF-allocations now. > BTW, do line numbers work correctly with these kinds of modules? > > Dave I couldn't be aware, thanks! crash> mod -s sctp MODULE NAME SIZE OBJECT FILE c9046a00 sctp 166780 /root/sctp.ko crash> mod -s ipv6 MODULE NAME SIZE OBJECT FILE c9030000 ipv6 236794 /root/ipv6.ko crash> dis -l xfrm6_get_tos 0xc90b9630 <xfrm6_get_tos>: xor %eax,%eax 0xc90b9632 <xfrm6_get_tos+2>: ret 0xc90b9633 <xfrm6_get_tos+3>: lea 0x0(%esi),%esi 0xc90b9639 <xfrm6_get_tos+9>: lea 0x0(%edi,%eiz,1),%edi This looks to be lost line number, however, next opposite procedure was well. Incidentally, sctp module's function line was well in both cases. crash> mod -s ipv6 MODULE NAME SIZE OBJECT FILE c9030000 ipv6 236794 /root/ipv6.ko crash> mod -s sctp MODULE NAME SIZE OBJECT FILE c9046a00 sctp 166780 /root/sctp.ko crash> dis -l xfrm6_get_tos /build/linux/net/ipv6/xfrm6_policy.c: 102 0xc90b9630 <xfrm6_get_tos>: xor %eax,%eax 0xc90b9632 <xfrm6_get_tos+2>: ret 0xc90b9633 <xfrm6_get_tos+3>: lea 0x0(%esi),%esi 0xc90b9639 <xfrm6_get_tos+9>: lea 0x0(%edi,%eiz,1),%edi -------------------- crash> sym -m sctp | grep MODULE c9046000 MODULE START: sctp c90f3b7c MODULE END: sctp crash> sym -m ipv6 | grep text c9090000 [.text]: section start c90bc080 [.text]: section end c90bc080 [.exit.text]: section start c90bc161 [.exit.text]: section end c90bc170 [.ref.text]: section start c90bc20c [.ref.text]: section end All of ipv6 text sections are surrounded by sctp virtual address range. I don't understand for detail and as far as my debugging, gdb internal implementation didn't allocate or refer the ipv6's LINETABLE() at GNU_GET_LINE_NUMBER operations. I could not found out corresponding condition from gdb-7.3.1/ but maybe -readnow is simple and proper way for this problem. I've tested and got the good result. // sprintf(buf, "add-symbol-file %s 0x%lx", sprintf(buf, "add-symbol-file %s 0x%lx -readnow", lm->mod_namelist, section_vaddr); Thanks, Toshi. -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
