2:04 a.m.
Hello Dave,
I add more pseudo section symbols which do not own any named symbol like
ffffffffa004ccf0 [.rodata.str1.1]: section start
ffffffffa004d14a [.rodata.str1.1]: section end
crash> rd ffffffffa004ccf0 -e ffffffffa004d14a
This can access section data without symbol.
This patch set way is learned from kernel/module.c layout_sections()
and probably be possible to integrate existing calculate_load_order_v1/2()
or add_symbol_file_kallsyms().
However, I can not confirm many kernel versions or architecrures,
thus my choice is verifying and updating to installed sections.
P.S.
I want to make feature in http://grsecurity.net/ PaX linux in crash utility.
The PaX patch changes module location by separating non contiguous RX/RW areas
which makes virtual address hole in module, also translates virtual address.
I tried but crash can not work out yet under PaX linux.
I'm resolving them with brief/rough way and
useful parts are merged into crash code, and then posting here.
If you can accept such a non mainline kernel feature in crash utility,
I would like to keep posting patch set until my whole work has done.
Thanks,
Toshi
7:49 a.m.
----- Original Message -----
Hello Dave,
I add more pseudo section symbols which do not own any named symbol like
ffffffffa004ccf0 [.rodata.str1.1]: section start
ffffffffa004d14a [.rodata.str1.1]: section end
crash> rd ffffffffa004ccf0 -e ffffffffa004d14a
This can access section data without symbol.
This patch set way is learned from kernel/module.c layout_sections()
and probably be possible to integrate existing calculate_load_order_v1/2()
or add_symbol_file_kallsyms().
However, I can not confirm many kernel versions or architecrures,
thus my choice is verifying and updating to installed sections.
What is the problem you're trying to solve here? That module memory
has been readable both before and after your last patch, and nobody
has ever even brought it up as an issue, and I don't see it as a problem.
P.S.
I want to make feature in http://grsecurity.net/ PaX linux in crash utility.
The PaX patch changes module location by separating non contiguous RX/RW areas
which makes virtual address hole in module, also translates virtual address.
I tried but crash can not work out yet under PaX linux.
I'm resolving them with brief/rough way and useful parts are merged into
crash code, and then posting here.
If you can accept such a non mainline kernel feature in crash utility,
I would like to keep posting patch set until my whole work has done.
I prefer not to, but it would depends upon how your proposed patch integrates
with the current code. If it can be reasonably segregated to that it's not
a maintenance burden, I'll consider it.
Dave
Thanks,
Toshi
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
2:13 a.m.
(2011/12/09 22:49), Dave Anderson wrote:
----- Original Message -----
> Hello Dave,
>
> I add more pseudo section symbols which do not own any named symbol like
> ffffffffa004ccf0 [.rodata.str1.1]: section start
> ffffffffa004d14a [.rodata.str1.1]: section end
> crash> rd ffffffffa004ccf0 -e ffffffffa004d14a
> This can access section data without symbol.
>
> This patch set way is learned from kernel/module.c layout_sections()
> and probably be possible to integrate existing calculate_load_order_v1/2()
> or add_symbol_file_kallsyms().
> However, I can not confirm many kernel versions or architecrures,
> thus my choice is verifying and updating to installed sections.
What is the problem you're trying to solve here? That module memory
has been readable both before and after your last patch, and nobody
has ever even brought it up as an issue, and I don't see it as a problem.
There are no problems in current implementation.
I just aimed to add SEC_FOUND to more sections beeing located in module memory
and display from "sym -m <mod>".
<diff the before/after results of "help -s" at linux-2.6.10: comment with
*>
- mod_text_start: ffffffffa0000000 (0)
- mod_etext_guess: ffffffffa001bc69 (1bc69)
- mod_rodata_start: ffffffffa001bc80 (1bc80)
+ mod_text_start: ffffffffa0027b80 (27b80)
+ mod_etext_guess: ffffffffa0027ba0 (27ba0)
+ mod_rodata_start: ffffffffa0000000 (0)
* This degrade is because of bad STREQ() in my patch set...
mod_data_start: ffffffffa0026860 (26860)
mod_bss_start: ffffffffa0027b80 (27b80)
mod_init_size: 0
mod_init_module_ptr: 0
mod_percpu_size: (not used)
mod_percpu: (not used)
- mod_sections: 23
- mod_section_data: 19ebca0
+ mod_sections: 25
+ mod_section_data: 17e3b70
.text prio: 3e flags: 1011f offset: 0 size: 1bc48
.init.text prio: 3e flags: 0011f offset: 0 size: 54
.exit.text prio: 3e flags: 1011f offset: 1bc48 size: 21
.rodata prio: 3a flags: 1012f offset: 1bc80 size: e28
.modinfo prio: 3a flags: 0012b offset: 0 size: 3f8
__param prio: 3a flags: 1012f offset: 1caa8 size: f0
- .rodata.str1.1 prio: 3a flags: 180012b offset: 0 size: 270
- .rodata.str1.8 prio: 3a flags: 180012b offset: 0 size: b4f
- .eh_frame prio: 3a flags: 0012f offset: 0 size: 3260
+ .rodata.str1.1 prio: 3a flags: 181012b offset: 1cb98 size: 270
+ .rodata.str1.8 prio: 3a flags: 181012b offset: 1ce08 size: b4f
+ .eh_frame prio: 3a flags: 1012f offset: 1d958 size: 3260
* Added SEC_FOUND(0x1000) flag and updated offset by my patch set.
These sections are actually existing in module memory at "mod_base + offset".
.data prio: 32 flags: 10127 offset: 26860 size: bc8
.log prio: 32 flags: 10123 offset: 27440 size: 1c0
.gnu.linkonce.this_module prio: 32 flags: 30127 offset: 27600 size: 580
.debug_str prio: 2a flags: 1802108 offset: 0 size: 423a0
.debug_ranges prio: 2a flags: 0210c offset: 0 size: ba0
.note.GNU-stack prio: 2a flags: 00108 offset: 0 size: 0
+ .symtab prio: 3a flags: 10009 offset: 20bb8 size: 3540
+ .strtab prio: 3a flags: 10009 offset: 240f8 size: 275f
* Forced SEC_FOUND flag by my patch set because 2.6.10 keeps symtab and strtab
in module memory at "mod_base + offset".
Come to think of it, this is not important for analysis very much
as against making possible destructive impacts at the same time.
So I decide to cancel this patch set at here.
> P.S.
>
> I want to make feature in http://grsecurity.net/ PaX linux in crash utility.
> The PaX patch changes module location by separating non contiguous RX/RW areas
> which makes virtual address hole in module, also translates virtual address.
> I tried but crash can not work out yet under PaX linux.
> I'm resolving them with brief/rough way and useful parts are merged into
> crash code, and then posting here.
>
> If you can accept such a non mainline kernel feature in crash utility,
> I would like to keep posting patch set until my whole work has done.
I prefer not to, but it would depends upon how your proposed patch integrates
with the current code. If it can be reasonably segregated to that it's not
a maintenance burden, I'll consider it.
Thanks for your consideration.
I'll try to propose it without hurting maintainability as possible
but if unfortunately rejected by any difficult reasons,
I am going to maintain by myself.
Thanks,
Toshi
Dave
> Thanks,
> Toshi
>
> --
> Crash-utility mailing list
> Crash-utility(a)redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility
>
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
9:19 a.m.
New subject: Patching more pseudo section symbols from layouts
----- Original Message -----
Come to think of it, this is not important for analysis very much
as against making possible destructive impacts at the same time.
So I decide to cancel this patch set at here.
OK good -- that patch was way too complex for just being able display
those additional section addresses. Plus, for example, it resulted in
this when run on RHEL5:
crash> mod -S
mod: Fail to resolve section layout for .data calc=31936 : orig=31904
mod: module section layout could not work out yet.
mod: ver: linux-2.6.18 mach: X86_64
MODULE NAME SIZE OBJECT FILE
ffffffff88007e80 ehci_hcd 65741
/lib/modules/2.6.18-128.el5/kernel/drivers/usb/host/ehci-hcd.ko
mod: Fail to resolve section layout for .data calc=22048 : orig=21984
mod: module section layout could not work out yet.
mod: ver: linux-2.6.18 mach: X86_64
ffffffff88017800 ohci_hcd 55925
/lib/modules/2.6.18-128.el5/kernel/drivers/usb/host/ohci-hcd.ko
mod: Fail to resolve section layout for .data calc=23552 : orig=23488
mod: module section layout could not work out yet.
mod: ver: linux-2.6.18 mach: X86_64
ffffffff88026e00 uhci_hcd 57433
/lib/modules/2.6.18-128.el5/kernel/drivers/usb/host/uhci-hcd.ko
mod: Fail to resolve section layout for .gnu.linkonce.this_module calc=61056 : orig=60800
mod: module section layout could not work out yet.
mod: ver: linux-2.6.18 mach: X86_64
ffffffff8803fd80 jbd 94257
/lib/modules/2.6.18-128.el5/kernel/fs/jbd/jbd.ko
mod: Fail to resolve section layout for .data calc=132800 : orig=132192
mod: module section layout could not work out yet.
mod: ver: linux-2.6.18 mach: X86_64
ffffffff8806ae00 ext3 168017
/lib/modules/2.6.18-128.el5/kernel/fs/ext3/ext3.ko
mod: Fail to resolve section layout for .data calc=158336 : orig=157792
mod: module section layout could not work out yet.
mod: ver: linux-2.6.18 mach: X86_64
ffffffff8809ca80 scsi_mod 196569
/lib/modules/2.6.18-128.el5/kernel/drivers/scsi/scsi_mod.ko
mod: Fail to resolve section layout for .data calc=22016 : orig=21952
mod: module section layout could not work out yet.
mod: ver: linux-2.6.18 mach: X86_64
...
But I will keep your first module-section-address-display patch
queued for crash-6.0.2.
Dave
2:17 p.m.
New subject: Patching more pseudo section symbols from layouts
----- Original Message -----
----- Original Message -----
>
> Come to think of it, this is not important for analysis very much
> as against making possible destructive impacts at the same time.
> So I decide to cancel this patch set at here.
OK good -- that patch was way too complex for just being able display
those additional section addresses. Plus, for example, it resulted in
this when run on RHEL5:
... [ cut ] ...
But I will keep your first module-section-address-display patch
queued for crash-6.0.2.
Hello Toshi,
Actually, after using this patch a bit, I've found that sometimes
it can be more confusing than helpful, especially with kernel modules
that only have a small number of symbols. Plus it does things like
this, which is not particularly helpful:
crash> sym -q odata
ffffffff8007f2a4 (t) .text.mark_rodata_ro
ffffffff8007f2a4 (T) mark_rodata_ro
ffffffff80274000 (r) .rodata
ffffffff80274000 (R) __start_rodata
ffffffff802ecbac (A) __end_rodata
ffffffff88004f20 (S) _MODULE_SECTION_START [.rodata] [ehci_hcd]
ffffffff88005140 (S) _MODULE_SECTION_END [.rodata] [ehci_hcd]
ffffffff88014ee0 (S) _MODULE_SECTION_START [.rodata] [ohci_hcd]
ffffffff88015100 (S) _MODULE_SECTION_END [.rodata] [ohci_hcd]
ffffffff88024160 (S) _MODULE_SECTION_START [.rodata] [uhci_hcd]
ffffffff880243e0 (S) _MODULE_SECTION_END [.rodata] [uhci_hcd]
ffffffff880382c0 (S) _MODULE_SECTION_START [.rodata] [jbd]
ffffffff8803885e (S) _MODULE_SECTION_END [.rodata] [jbd]
ffffffff8805c920 (S) _MODULE_SECTION_START [.rodata] [ext3]
ffffffff8805da02 (S) _MODULE_SECTION_END [.rodata] [ext3]
ffffffff8807fe20 (S) _MODULE_SECTION_START [.rodata] [scsi_mod]
...
But presumably you had your reasons for implementing it, so I'll
keep your patch in place -- but only as an option to the "mod" command.
So in order to have module symbol lists intermingled with section
start/end address pseudo-symbols, I've added a "mod -g" flag that
can be used in conjunction with "-s" or "-S". Hopefully that works
OK for you.
Thanks,
Dave
6:15 p.m.
New subject: Patching more pseudo section symbols from layouts
(2011/12/16 5:17), Dave Anderson wrote:
----- Original Message -----
>
>
> ----- Original Message -----
>>
>> Come to think of it, this is not important for analysis very much
>> as against making possible destructive impacts at the same time.
>> So I decide to cancel this patch set at here.
>
> OK good -- that patch was way too complex for just being able display
> those additional section addresses. Plus, for example, it resulted in
> this when run on RHEL5:
> ... [ cut ] ...
> But I will keep your first module-section-address-display patch
> queued for crash-6.0.2.
Hello Toshi,
Actually, after using this patch a bit, I've found that sometimes
it can be more confusing than helpful, especially with kernel modules
that only have a small number of symbols. Plus it does things like
this, which is not particularly helpful:
Hello Dave,
At first, thanks for your proper arrangement.
I could not care this broken impact of the symbol search outputs,
it looked just making cumberers.
I'm going to use "mod -gs" when I need to load section pseudo symbols.
Thanks a lot,
Toshi.
crash> sym -q odata
ffffffff8007f2a4 (t) .text.mark_rodata_ro
ffffffff8007f2a4 (T) mark_rodata_ro
ffffffff80274000 (r) .rodata
ffffffff80274000 (R) __start_rodata
ffffffff802ecbac (A) __end_rodata
ffffffff88004f20 (S) _MODULE_SECTION_START [.rodata] [ehci_hcd]
ffffffff88005140 (S) _MODULE_SECTION_END [.rodata] [ehci_hcd]
ffffffff88014ee0 (S) _MODULE_SECTION_START [.rodata] [ohci_hcd]
ffffffff88015100 (S) _MODULE_SECTION_END [.rodata] [ohci_hcd]
ffffffff88024160 (S) _MODULE_SECTION_START [.rodata] [uhci_hcd]
ffffffff880243e0 (S) _MODULE_SECTION_END [.rodata] [uhci_hcd]
ffffffff880382c0 (S) _MODULE_SECTION_START [.rodata] [jbd]
ffffffff8803885e (S) _MODULE_SECTION_END [.rodata] [jbd]
ffffffff8805c920 (S) _MODULE_SECTION_START [.rodata] [ext3]
ffffffff8805da02 (S) _MODULE_SECTION_END [.rodata] [ext3]
ffffffff8807fe20 (S) _MODULE_SECTION_START [.rodata] [scsi_mod]
...
But presumably you had your reasons for implementing it, so I'll
keep your patch in place -- but only as an option to the "mod" command.
So in order to have module symbol lists intermingled with section
start/end address pseudo-symbols, I've added a "mod -g" flag that
can be used in conjunction with "-s" or "-S". Hopefully that works
OK for you.
Thanks,
Dave
4581
days inactive
4588
days old
devel@lists.crash-utility.osci.io
5 comments
2 participants
participants (2)
-
Dave Anderson -
Toshikazu Nakayama