[Crash-utility] submission about PaX linux support

[Toshikazu Nakayama]

(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.