Fix ELF output with overlapping sections
Subsystems (2)
PATCH 1/1 Fix ELF output with overlapping sections
I have a core dump with following program headers on IA64:
LOAD 0x0000000000001f4c 0xa000000100000000 0x0000000004000000
0x000000000055c4a0 0x000000000055c4a0 RWE 0
...
LOAD 0x00000000044fc3ec 0xe000000004000000 0x0000000004000000
0x0000000000c92000 0x0000000000c92000 RWE 0The interesting thing is the overlap in the physical address space. write_elf_pages() assumes that there's no overlap because it looks only for the file offset according to the physical start address and silently assumes that the length matches.
This patch tries to address that problem. At least it works here. Before I could not read the dump file with `crash' because MAGIC_START was missing (it's in the 0x4000000 section).
--- makedumpfile.c | 50 +++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 45 insertions(+), 5 deletions(-)
makedumpfile.c +45 -5
@@ -64,6 +64,43 @@ paddr_to_offset(struct DumpInfo *info, ureturn offset; } +/** +* Sames as paddr_to_offset() but makes sure that the complete range is covered +* by the segment +*/ +off_t +paddr_to_offset_range (struct DumpInfo *info,unsigned long long paddr,unsigned long len) +{ +int i; +off_t offset; +struct pt_load_segment *pls; + +for (i = offset =0 ; i < info->num_load_memory; i++) { + pls = &info->pt_load_segments[i]; +if ((paddr >= pls->phys_start) + && (paddr <= pls->phys_end)) { + +/* check the length and also consider adjacent sections */ +unsigned long long end = pls->phys_end; +int j = i+1 ; + +while (j < info->num_load_memory && + (info->pt_load_segments[j-1 ].phys_end + == info->pt_load_segments[j].phys_start)) { + end = info->pt_load_segments[j].phys_end; + j++; + } + +if (paddr + len <= end) { + offset = (off_t)(paddr - pls->phys_start) + + pls->file_offset; +break ; + } + } + } +return offset; +} +unsigned long long vaddr_to_paddr (struct DumpInfo *info,unsigned long long vaddr) {
@@ -3777,6 +3814,7 @@ write_elf_pages(struct DumpInfo *info) pfn_end++;for (pfn = pfn_start; pfn < pfn_end; pfn++) { +if (!is_dumpable (&bitmap2, pfn)) { num_excluded++;if ((pfn == pfn_end -1 ) && frac_tail)
@@ -3934,13 +3972,19 @@ write_elf_pages(struct DumpInfo *info) goto out; } +if (info->flag_elf64)/* ELF64 */ + bufsz_remain = load64.p_filesz; +else /* ELF32 */ + bufsz_remain = load32.p_filesz; +/* * Write a PT_LOAD segment. */ - off_memory =paddr_to_offset (info, paddr); + off_memory =paddr_to_offset_range (info, paddr, bufsz_remain);if (!off_memory) {ERRMSG ("Can't convert physaddr(%llx) to a offset.\n" , paddr); +printf ("paddr = 0x%llx, bufsz_remain=%lld\n" , paddr, bufsz_remain); goto out; } if (lseek(info->fd_memory, off_memory, SEEK_SET)
@@ -3949,10 +3993,6 @@ write_elf_pages(struct DumpInfo *info) info->name_memory, strerror(errno)); goto out; } -if (info->flag_elf64)/* ELF64 */ - bufsz_remain = load64.p_filesz; -else /* ELF32 */ - bufsz_remain = load32.p_filesz;while (bufsz_remain >0 ) {if ((num_dumped % per) ==0 )
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Hi Bernhard,
Quoted 8 lines · Bernhard Walle
I have a core dump with following program headers on IA64:
LOAD
0x0000000000001f4c0xa0000001000000000x00000000040000000x000000000055c4a0 0x000000000055c4a0 RWE 0 ... LOAD 0x00000000044fc3ec 0xe000000004000000 0x0000000004000000 0x0000000000c92000 0x0000000000c92000 RWE 0
Quoted 4 lines
The interesting thing is the overlap in the physical address space.
write_elf_pages()assumes that there's no overlap because it looks only for the file offset according to the physical start address and silently assumes that the length matches.
Thank you for the patch.
I'm worry that the overlapping spaces may have the same p_filesz. I think it is certain to check it by p_offset, and created the attached patch. Please let me know your opinion.
BTW, I don't know the reason why your system's /proc/vmcore has the overlapping physical address. If you know it, please let me know.
Thanks
Ken'ichi Ohmichi
------------------------------------------------------------
---
makedumpfile.c renamed from v1.1.3/makedumpfile.c +31 -4
@@ -2561,6 +2561,33 @@ out:return ret; } +/* +* Sames as paddr_to_offset() but makes sure that the specified offset (hint) +* in the segment. +*/ +off_t +paddr_to_offset2 (struct DumpInfo *info,unsigned long long paddr,off_t hint) +{ +int i; +off_t offset; +unsigned long long len; +struct pt_load_segment *pls; + +for (i = offset =0 ; i < info->num_load_memory; i++) { + pls = &info->pt_load_segments[i]; + len = pls->phys_end - pls->phys_start; +if ((paddr >= pls->phys_start) + && (paddr < pls->phys_end) + && (hint >= pls->file_offset) + && (hint < pls->file_offset + len)) { + offset = (off_t)(paddr - pls->phys_start) + + pls->file_offset; +break ; + } + } +return offset; +} +unsigned long long page_to_pfn (struct DumpInfo *info,unsigned long page) {
@@ -3462,7 +3489,6 @@ write_elf_pages(struct DumpInfo *info) off_seg_load = info->offset_load_dumpfile; cd_seg.offset = info->offset_load_dumpfile; - off_memory =0 ;if (info->flag_elf64) {/* ELF64 */ cd_hdr.offset =sizeof (Elf64_Ehdr) +sizeof (Elf64_Phdr);
@@ -3488,7 +3514,7 @@ write_elf_pages(struct DumpInfo *info) }if (load64.p_type !=PT_LOAD )continue ; - + off_memory= load64.p_offset; paddr = load64.p_paddr; pfn_start = load64.p_paddr / page_size; pfn_end = (load64.p_paddr+ load64.p_memsz)/page_size;
@@ -3501,6 +3527,7 @@ write_elf_pages(struct DumpInfo *info) }if (load32.p_type !=PT_LOAD )continue ; + off_memory= load32.p_offset; paddr = load32.p_paddr; pfn_start = load32.p_paddr / page_size; pfn_end = (load32.p_paddr+ load32.p_memsz)/page_size;
@@ -3588,7 +3615,7 @@ write_elf_pages(struct DumpInfo *info)/* * Write a PT_LOAD segment. */ - off_memory =paddr_to_offset (info, paddr); + off_memory =paddr_to_offset2 (info, paddr, off_memory);if (!off_memory) {ERRMSG ("Can't convert physaddr(%llx) to a offset.\n" , paddr);
@@ -3680,7 +3707,7 @@ write_elf_pages(struct DumpInfo *info)/* * Write a PT_LOAD segment. */ - off_memory =paddr_to_offset (info, paddr); + off_memory =paddr_to_offset2 (info, paddr, off_memory);if (!off_memory) {ERRMSG ("Can't convert physaddr(%llx) to a offset.\n" , paddr);
_
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Hello Ken'ichi,
Quoted 14 lines · Ken'ichi Ohmichi
Quoted 8 lines · Bernhard Walle
I have a core dump with following program headers on IA64:
LOAD
0x0000000000001f4c0xa0000001000000000x00000000040000000x000000000055c4a0 0x000000000055c4a0 RWE 0 ... LOAD 0x00000000044fc3ec 0xe000000004000000 0x0000000004000000 0x0000000000c92000 0x0000000000c92000 RWE 0Quoted 4 lines
The interesting thing is the overlap in the physical address space.
write_elf_pages()assumes that there's no overlap because it looks only for the file offset according to the physical start address and silently assumes that the length matches.
Quoted 8 lines
Thank you for the patch.
I'm worry that the overlapping spaces may have the samep_filesz. I think it is certain to check it byp_offset, and created the attached patch. Please let me know your opinion.BTW, I don't know the reason why your system's
/proc/vmcorehas the overlapping physical address. If you know it, please let me know.
thanks for the patch. It looks more safe than my attempt to fix it. I tested your patch on the machine on which I originally had my problem. It worked without any problems.
So I vote for applying the patch to your code base. :-)
Thanks,
Bernhard
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Hi Bernhard,
Quoted 21 lines · Bernhard Walle
Quoted 20 lines · Ken'ichi Ohmichi
Quoted 8 lines · Bernhard Walle
I have a core dump with following program headers on IA64:
LOAD
0x0000000000001f4c0xa0000001000000000x00000000040000000x000000000055c4a0 0x000000000055c4a0 RWE 0 ... LOAD 0x00000000044fc3ec 0xe000000004000000 0x0000000004000000 0x0000000000c92000 0x0000000000c92000 RWE 0Quoted 4 lines
The interesting thing is the overlap in the physical address space.
write_elf_pages()assumes that there's no overlap because it looks only for the file offset according to the physical start address and silently assumes that the length matches.Thank you for the patch.
I'm worry that the overlapping spaces may have the samep_filesz. I think it is certain to check it byp_offset, and created the attached patch. Please let me know your opinion.
Quoted 8 lines
Quoted 2 lines
BTW, I don't know the reason why your system's
/proc/vmcorehas the overlapping physical address. If you know it, please let me know.thanks for the patch. It looks more safe than my attempt to fix it. I tested your patch on the machine on which I originally had my problem. It worked without any problems.
So I vote for applying the patch to your code base. :-)
Thank you for the test !
I will merge it.
Thanks
Ken'ichi Ohmichi
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
Quoted 3 lines · Ken'ichi Ohmichi
BTW, I don't know the reason why your system's
/proc/vmcorehas the overlapping physical address. If you know it, please let me know.
/*
* Certain architectures such as x86_64 and ia64 require a separate
* PT_LOAD program header for the kernel. This is controlled through
* info->kern_size.
*
* The separate PT_LOAD program header is required either because the
* kernel is mapped at a different location than the rest of the
* physical memory or because we need to support relocatable kernels.
* Or both as on x86_64.
*
* In the relocatable kernel case this PT_LOAD segment is used to tell
* where the kernel was actually loaded which may be different from
* the load address present in the vmlinux file.
*
* The extra kernel PT_LOAD program header results in a vmcore file
* which is larger than the size of the physical memory. This is
* because the memory for the kernel is present both in the kernel
* PT_LOAD program header and in the physical RAM program headers. */
Thanks,
Bernhard
_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec