(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@xxxxxxxxxx
>> https://www.redhat.com/mailman/listinfo/crash-utility
>>
>
> --
> Crash-utility mailing list
> Crash-utility@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/crash-utility
>
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
