1:57 a.m.
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
--------
Toshikazu Nakayama (9):
add PaX linux staff from linux-2.6.27.
setup PaX module structure members and pseudos
manufacture module's dumping symbol data
use IN_MODULE macros for ec->st_value
define new namespace command to sort by per module order
vefiry PaX module RW area, also fix leak
catch apt module symbol
sharpen vague module data with found out section
RW for lowest or highest module virtual address
defs.h | 42 +++++++++++-
kernel.c | 58 ++++++++++++++++-
symbols.c | 221 +++++++++++++++++++++++++++++++++++++++++++++++++++++--------
3 files changed, 291 insertions(+), 30 deletions(-)
1:42 p.m.
----- 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.
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?
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?
Also, that "gap" calculation is not restricted to PAX()-only?
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().
BTW, do line numbers work correctly with these kinds of modules?
Dave
--------
Toshikazu Nakayama (9):
add PaX linux staff from linux-2.6.27.
setup PaX module structure members and pseudos
manufacture module's dumping symbol data
use IN_MODULE macros for ec->st_value
define new namespace command to sort by per module order
vefiry PaX module RW area, also fix leak
catch apt module symbol
sharpen vague module data with found out section
RW for lowest or highest module virtual address
defs.h | 42 +++++++++++-
kernel.c | 58 ++++++++++++++++-
symbols.c | 221
+++++++++++++++++++++++++++++++++++++++++++++++++++++--------
3 files changed, 291 insertions(+), 30 deletions(-)
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
2:27 a.m.
(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.
8:11 a.m.
----- Original Message -----
(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.
OK, I appreciate that.
...
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);
Interesting -- are you only seeing this behaviour with your PaX modules?
I ask because I saw similar behavior with module line numbers after the
gdb-7.3.1 merge, but was able to fix it in crash-6.0.1 by reading in the
second-stage debuginfo data whenever a specific line number was requested:
- Fix for the X86 kernel module line-number capability on some kernels.
It is unclear why only some kernel versions exhibit this problem,
but the newly-embedded gdb version 7.3.1 has changed behaviour such
that the addrmap arrays of module text address blocks may contain
the module text offset values instead of their loaded vmalloc
addresses, and so without the patch, there is no "match" for the
vmalloc address when searching for its line number information.
It is fixed by doing a preliminary symbol search before accessing
the line-number access routine.
(anderson(a)redhat.com)
with this patch:
+++ gdb-7.3.1/gdb/symtab.c
@@ -4951,10 +4951,17 @@ static void
gdb_get_line_number(struct gnu_request *req)
{
struct symtab_and_line sal;
+ struct symbol *sym;
CORE_ADDR pc;
#define LASTCHAR(s) (s[strlen(s)-1])
+ /*
+ * Prime the addrmap pump.
+ */
+ if (req->name)
+ sym = lookup_symbol(req->name, 0, VAR_DOMAIN, 0);
+
pc = req->addr;
sal = find_pc_line(pc, 0);
I could add the --readnow, but I'm thinking that it could cause a
significant amount of unnecessary debuginfo data to be read in and
stored.
Dave
8:17 a.m.
----- Original Message -----
> 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.
OK, I appreciate that.
Just to be clear -- I will not be applying your patch at this time.
If there ever becomes a groundswell of demand for this, I'll
reconsider it in the future.
Thanks,
Dave
4723
days inactive
4724
days old
devel@lists.crash-utility.osci.io
4 comments
2 participants
participants (2)
-
Dave Anderson -
Toshikazu Nakayama