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