Skip to contentSkip to conversation

Fix ELF output with overlapping sections

PATCH In review Bernhard Walle 2 participants 5 messages May 18, 2007 – Jun 1, 2007

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

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    0

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.

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, u
 	return 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

#1 lore raw

Hi Bernhard,

Quoted 8 lines · Bernhard Walle

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    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
diff -puN backup/v1.1.3/makedumpfile.c a/makedumpfile.c
@@ -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

#2 lore raw

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 0x0000000000001f4c 0xa000000100000000 0x0000000004000000

                0x000000000055c4a0 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.

Quoted 8 lines

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 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

#3 lore raw

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 0x0000000000001f4c 0xa000000100000000 0x0000000004000000

                0x000000000055c4a0 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.

Quoted 8 lines
Quoted 2 lines

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 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

#4 lore raw
In reply to Ken'ichi Ohmichi
Quoted 3 lines · Ken'ichi Ohmichi

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.

/*
* 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