Fix refiltering when kaslr enabled

If we have to erase a symbol from vmcore whose address is not present in vmcoreinfo, then we need to pass vmlinux as well to get the symbol address.
When kaslr is enabled, virtual address of all the kernel symbols are randomized with an offset. vmlinux always has a static address, but all the arch specific calculation are based on run time kernel address. So we need to find a way to translate symbol address from vmlinux to kernel run time address.

without this patch:

    # makedumpfile --split  -d 5 -x vmlinux --config scrub.conf vmcore dumpfile_{1,2,3}

readpage_kdump_compressed: pfn(f97ea) is excluded from vmcore.
readmem: type_addr: 1, addr:f97eaff8, size:8
vtop4_x86_64: Can't get pml4 (page_dir:f97eaff8).
readmem: Can't convert a virtual address(ffffffff819f1284) to physical address.
readmem: type_addr: 0, addr:ffffffff819f1284, size:390
check_release: Can't get the address of system_utsname.

After this patch check_release() is ok, and also we are able to erase symbol from vmcore.

Signed-off-by Pratyush Anand <[email protected]>

---
 arch/x86_64.c  | 23 +++++++++++++++++++++++
 erase_info.c   |  1 +
 makedumpfile.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
 makedumpfile.h | 15 +++++++++++++++
 4 files changed, 83 insertions(+)

arch/x86_64.c +23 -0

index e978a36f8878..ab5aae8f1b26 100644
@@ -33,6 +33,29 @@ get_xen_p2m_mfn(void)
 	return NOT_FOUND_LONG_VALUE;
 }
 
+unsigned long
+get_kaslr_offset_x86_64(unsigned long vaddr)
+{
+	unsigned long sym_vmcoreinfo, sym_vmlinux;
+
+	if (!info->kaslr_offset) {
+		sym_vmlinux = get_symbol_addr("_stext");
+		if (sym_vmlinux == NOT_FOUND_SYMBOL)
+			return 0;
+		sym_vmcoreinfo = read_vmcoreinfo_symbol(STR_SYMBOL("_stext"));
+		info->kaslr_offset = sym_vmcoreinfo - sym_vmlinux;
+	}
+	if (vaddr >= __START_KERNEL_map &&
+			vaddr < __START_KERNEL_map + info->kaslr_offset)
+		return info->kaslr_offset;
+	else
+		/*
+		 * TODO: we need to check if it is vmalloc/vmmemmap/module
+		 * address, we will have different offset
+		 */
+		return 0;
+}
+
 static int
 get_page_offset_x86_64(void)
 {

erase_info.c +1 -0

index f2ba9149e93e..60abfa1a1adf 100644
@@ -1088,6 +1088,7 @@ resolve_config_entry(struct config_entry *ce, unsigned long long base_vaddr,
 							ce->line, ce->name);
 			return FALSE;
 		}
+		ce->sym_addr += get_kaslr_offset(ce->sym_addr);
 		ce->type_name = get_symbol_type_name(ce->name,
 					DWARF_INFO_GET_SYMBOL_TYPE,
 					&ce->size, &ce->type_flag);

makedumpfile.c +18 -0

index 301772a8820c..7e78641917d7 100644
@@ -3782,6 +3782,46 @@ free_for_parallel()
 }
 
 int
+find_kaslr_offsets()
+{
+	off_t offset;
+	unsigned long size;
+	int ret = FALSE;
+
+	get_vmcoreinfo(&offset, &size);
+
+	if (!(info->name_vmcoreinfo = strdup(FILENAME_VMCOREINFO))) {
+		MSG("Can't duplicate strings(%s).\n", FILENAME_VMCOREINFO);
+		return FALSE;
+	}
+	if (!copy_vmcoreinfo(offset, size))
+		goto out;
+
+	if (!open_vmcoreinfo("r"))
+		goto out;
+

makedumpfile.c +16 -0

+
+	close_vmcoreinfo();
+
+	ret = TRUE;
+out:
+	free(info->name_vmcoreinfo);
+	info->name_vmcoreinfo = NULL;
+
+	return ret;
+}
+
+int
 initial(void)
 {
 	off_t offset;

@@ -3833,6 +3873,9 @@ initial(void)
 		set_dwarf_debuginfo("vmlinux", NULL,
 					info->name_vmlinux, info->fd_vmlinux);
 
+		if (has_vmcoreinfo() && !find_kaslr_offsets())
+			return FALSE;
+
 		if (!get_symbol_info())
 			return FALSE;
 

@@ -11031,6 +11074,7 @@ main(int argc, char *argv[])
 	info->fd_memory = -1;
 	info->fd_dumpfile = -1;
 	info->fd_bitmap = -1;
+	info->kaslr_offset = 0;
 	initialize_tables();
 
 	/*

makedumpfile.h +14 -0

index e32e567018f6..0d358be8caac 100644
@@ -253,10 +253,14 @@ static inline int string_exists(char *s) { return (s ? TRUE : FALSE); }
 #define SYMBOL_INIT(symbol, str_symbol) \
 do { \
 	SYMBOL(symbol) = get_symbol_addr(str_symbol); \
+	if (SYMBOL(symbol) != NOT_FOUND_SYMBOL) \
+		SYMBOL(symbol) += info->kaslr_offset; \
 } while (0)
 #define SYMBOL_INIT_NEXT(symbol, str_symbol) \
 do { \
 	SYMBOL(symbol) = get_next_symbol_addr(str_symbol); \
+	if (SYMBOL(symbol) != NOT_FOUND_SYMBOL) \
+		SYMBOL(symbol) += info->kaslr_offset; \
 } while (0)
 #define WRITE_SYMBOL(str_symbol, symbol) \
 do { \

@@ -838,6 +842,7 @@ int get_xen_info_arm64(void);
 #define get_phys_base()		get_phys_base_arm64()
 #define get_machdep_info()	get_machdep_info_arm64()
 #define get_versiondep_info()	get_versiondep_info_arm64()
+#define get_kaslr_offset(X)	FALSE
 #define get_xen_basic_info_arch(X) get_xen_basic_info_arm64(X)
 #define get_xen_info_arch(X) get_xen_info_arm64(X)
 #define is_phys_addr(X)		stub_true_ul(X)

@@ -851,6 +856,7 @@ unsigned long long vaddr_to_paddr_arm(unsigned long vaddr);
 #define get_phys_base()		get_phys_base_arm()
 #define get_machdep_info()	get_machdep_info_arm()
 #define get_versiondep_info()	stub_true()
+#define get_kaslr_offset(X)	FALSE
 #define vaddr_to_paddr(X)	vaddr_to_paddr_arm(X)
 #define is_phys_addr(X)		stub_true_ul(X)
 #endif /* arm */

@@ -863,11 +869,13 @@ unsigned long long vaddr_to_paddr_x86(unsigned long vaddr);
 #define get_phys_base()		stub_true()
 #define get_machdep_info()	get_machdep_info_x86()
 #define get_versiondep_info()	get_versiondep_info_x86()
+#define get_kaslr_offset(X)	FALSE
 #define vaddr_to_paddr(X)	vaddr_to_paddr_x86(X)
 #define is_phys_addr(X)		stub_true_ul(X)
 #endif /* x86 */
 
 #ifdef __x86_64__
+unsigned long get_kaslr_offset_x86_64(unsigned long vaddr);
 int get_phys_base_x86_64(void);
 int get_machdep_info_x86_64(void);
 int get_versiondep_info_x86_64(void);

@@ -876,6 +884,7 @@ unsigned long long vtop4_x86_64(unsigned long vaddr);
 #define get_phys_base()		get_phys_base_x86_64()
 #define get_machdep_info()	get_machdep_info_x86_64()
 #define get_versiondep_info()	get_versiondep_info_x86_64()
+#define get_kaslr_offset(X)	get_kaslr_offset_x86_64(X)
 #define vaddr_to_paddr(X)	vtop4_x86_64(X)
 #define is_phys_addr(X)		stub_true_ul(X)
 #endif /* x86_64 */

@@ -888,6 +897,7 @@ unsigned long long vaddr_to_paddr_ppc64(unsigned long vaddr);
 #define get_phys_base()		stub_true()
 #define get_machdep_info()	get_machdep_info_ppc64()
 #define get_versiondep_info()	get_versiondep_info_ppc64()
+#define get_kaslr_offset(X)	FALSE
 #define vaddr_to_paddr(X)	vaddr_to_paddr_ppc64(X)
 #define is_phys_addr(X)		stub_true_ul(X)
 #endif          /* powerpc64 */

@@ -899,6 +909,7 @@ unsigned long long vaddr_to_paddr_ppc(unsigned long vaddr);
 #define get_phys_base()		stub_true()
 #define get_machdep_info()	get_machdep_info_ppc()
 #define get_versiondep_info()	stub_true()
+#define get_kaslr_offset(X)	FALSE
 #define vaddr_to_paddr(X)	vaddr_to_paddr_ppc(X)
 #define is_phys_addr(X)		stub_true_ul(X)
 #endif          /* powerpc32 */

@@ -911,6 +922,7 @@ int is_iomem_phys_addr_s390x(unsigned long addr);
 #define get_phys_base()		stub_true()
 #define get_machdep_info()	get_machdep_info_s390x()
 #define get_versiondep_info()	stub_true()
+#define get_kaslr_offset(X)	FALSE
 #define vaddr_to_paddr(X)	vaddr_to_paddr_s390x(X)
 #define is_phys_addr(X)		is_iomem_phys_addr_s390x(X)
 #endif          /* s390x */

@@ -923,6 +935,7 @@ unsigned long long vaddr_to_paddr_ia64(unsigned long vaddr);
 #define get_machdep_info()	get_machdep_info_ia64()
 #define get_phys_base()		get_phys_base_ia64()
 #define get_versiondep_info()	stub_true()
+#define get_kaslr_offset(X)	FALSE
 #define vaddr_to_paddr(X)	vaddr_to_paddr_ia64(X)
 #define VADDR_REGION(X)		(((unsigned long)(X)) >> REGION_SHIFT)
 #define is_phys_addr(X)		stub_true_ul(X)

@@ -1152,6 +1165,7 @@ struct DumpInfo {
 	int		vmemmap_psize;
 	int		vmemmap_cnt;
 	struct ppc64_vmemmap	*vmemmap_list;
+	unsigned long	kaslr_offset;
 
 	/*
 	 * page table info for ppc64

makedumpfile.c free_for_parallel() · line 3812

Quoted 2 lines

makedumpfile.c +2 -0

+	 */
+	get_kaslr_offset(SYMBOL(_stext));

Looks like acquiring "KERNELOFFSET" in read_vmcoreinfo() should be enough here.

We can get kaslr offset directly from the vmcoreinfo because the compressed dumpfile contains vmcoreinfo as well in case of flag_refiltering, also x86_64 kernel has exported "vmcoreinfo_append_str("KERNELOFFSET=%lx\n", kaslr_offset());"

Hi All,

We came across another failure in makedumpfile when kaslr is enabled. This failure occurs when we try re-filtering. We try to erase some symbol from a dumpfile which was copied/compressed from /proc/vmcore using makedumpfile.

We have very limited symbol information in vmcoreinfo. So symbols to be erased may not be available in vmcoreinfo and we look for it in vmlinux. However, symbol address from vmlinux is a static address which differs from run time address with KASLR_OFFSET. Therefore, reading any "virtual address of vmlinux" from vmcore is not possible.

These patches finds runtime KASLR offset and then calculates run time address of symbols read from vmlinux.

Since, I am not an expert of x86, and these patches touch x86 part of makedumpfile, therefore I have CCed x86 experts. Please, provide your review comment and let me know if you think there could have been a better way to resolve this issue.

thanks

~Pratyush

Pratyush Anand (2):
makedumpfile: add runtime kaslr offset if it exists
x86_64: calculate page_offset in case of re-filtering

 arch/x86_64.c  | 45 +++++++++++++++++++++++++++++++++++++++++++--
 erase_info.c   |  1 +
 makedumpfile.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
 makedumpfile.h | 15 +++++++++++++++
 4 files changed, 103 insertions(+), 2 deletions(-)

Signature · 7 lines

2.9.3


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Hi All,

We came across another failure in makedumpfile when kaslr is enabled. This failure occurs when we try re-filtering. We try to erase some symbol from a dumpfile which was copied/compressed from /proc/vmcore using makedumpfile.

We have very limited symbol information in vmcoreinfo. So symbols to be erased may not be available in vmcoreinfo and we look for it in vmlinux. However, symbol address from vmlinux is a static address which differs from run time address with KASLR_OFFSET. Therefore, reading any "virtual address of vmlinux" from vmcore is not possible.

These patches finds runtime KASLR offset and then calculates run time address of symbols read from vmlinux.

Since, I am not an expert of x86, and these patches touch x86 part of makedumpfile, therefore I have CCed x86 experts. Please, provide your review comment and let me know if you think there could have been a better way to resolve this issue.

thanks

~Pratyush

Pratyush Anand (2):
makedumpfile: add runtime kaslr offset if it exists
x86_64: calculate page_offset in case of re-filtering

arch/x86_64.c  | 45 +++++++++++++++++++++++++++++++++++++++++++--
erase_info.c   |  1 +
makedumpfile.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
makedumpfile.h | 15 +++++++++++++++
4 files changed, 103 insertions(+), 2 deletions(-)

--
2.9.3

Hello Pratyush,

Thanks for your report, I have received this.
I'm on vacation until Mar 8, I'll review it when I return from vacation.

Thanks,
Atsushi Kumagai

Quoted 36 lines

Hi All,

We came across another failure in makedumpfile when kaslr is enabled. This failure occurs when we try re-filtering. We try to erase some symbol from a dumpfile which was copied/compressed from /proc/vmcore using makedumpfile.

We have very limited symbol information in vmcoreinfo. So symbols to be erased may not be available in vmcoreinfo and we look for it in vmlinux. However, symbol address from vmlinux is a static address which differs from run time address with KASLR_OFFSET. Therefore, reading any "virtual address of vmlinux" from vmcore is not possible.

These patches finds runtime KASLR offset and then calculates run time address of symbols read from vmlinux.

Since, I am not an expert of x86, and these patches touch x86 part of makedumpfile, therefore I have CCed x86 experts. Please, provide your review comment and let me know if you think there could have been a better way to resolve this issue.

thanks

~Pratyush

Pratyush Anand (2):
makedumpfile: add runtime kaslr offset if it exists
x86_64: calculate page_offset in case of re-filtering

arch/x86_64.c  | 45 +++++++++++++++++++++++++++++++++++++++++++--
erase_info.c   |  1 +
makedumpfile.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
makedumpfile.h | 15 +++++++++++++++
4 files changed, 103 insertions(+), 2 deletions(-)

--
2.9.3

Hi Atsushi,

Quoted 4 lines · Atsushi Kumagai

Hello Pratyush,

Thanks for your report, I have received this.
I'm on vacation until Mar 8, I'll review it when I return from vacation.

Any further comment on it?
Otherwise, I will send a v2 after accommodating concern from Xunlei.

~Pratyush

Quoted 41 lines

Thanks,
Atsushi Kumagai

Quoted 36 lines

Hi All,

We came across another failure in makedumpfile when kaslr is enabled. This failure occurs when we try re-filtering. We try to erase some symbol from a dumpfile which was copied/compressed from /proc/vmcore using makedumpfile.

We have very limited symbol information in vmcoreinfo. So symbols to be erased may not be available in vmcoreinfo and we look for it in vmlinux. However, symbol address from vmlinux is a static address which differs from run time address with KASLR_OFFSET. Therefore, reading any "virtual address of vmlinux" from vmcore is not possible.

These patches finds runtime KASLR offset and then calculates run time address of symbols read from vmlinux.

Since, I am not an expert of x86, and these patches touch x86 part of makedumpfile, therefore I have CCed x86 experts. Please, provide your review comment and let me know if you think there could have been a better way to resolve this issue.

thanks

~Pratyush

Pratyush Anand (2):
makedumpfile: add runtime kaslr offset if it exists
x86_64: calculate page_offset in case of re-filtering

arch/x86_64.c  | 45 +++++++++++++++++++++++++++++++++++++++++++--
erase_info.c   |  1 +
makedumpfile.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
makedumpfile.h | 15 +++++++++++++++
4 files changed, 103 insertions(+), 2 deletions(-)

--
2.9.3

Quoted 8 lines

Hi Atsushi,

Quoted 4 lines · Atsushi Kumagai

Hello Pratyush,

Thanks for your report, I have received this.
I'm on vacation until Mar 8, I'll review it when I return from vacation.

Quoted 2 lines

Any further comment on it?
Otherwise, I will send a v2 after accommodating concern from Xunlei.

Unfortunately, it doesn't seem like I can make time anymore for review this week, but at least this patch doesn't seem to work in my environment (linux 4.8 without kaslr). Do you have any ideas ?

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6be49f5 in fseek () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-13.el7.x86_64 elfutils-libelf-0.163-3.el7.x86_64 elfutils-libs-0.163-3.el7.x86_64 glibc-2.17-105.el7.x86_64 libgcc-4.8.5-4.el7.x86_64 libstdc++-4.8.5-4.el7.x86_64 snappy-1.1.0-3.el7.x86_64 xz-libs-5.1.2-12alpha.el7.x86_64 zlib-1.2.7-15.el7.x86_64 (gdb) bt

#0  0x00007ffff6be49f5 in fseek () from /lib64/libc.so.6
#1  0x0000000000429d38 in read_vmcoreinfo_symbol (str_symbol=0x44cb0c "SYMBOL(_stext)=") at makedumpfile.c:2384
#2  0x000000000042097a in get_kaslr_offset_x86_64 (vaddr=18446744071589596288) at arch/x86_64.c:45
#3  0x0000000000414310 in resolve_config_entry (ce=0x701370, base_vaddr=<optimized out>, base_struct_name=0x0)
    at erase_info.c:1091
#4  0x0000000000415a89 in get_config_symbol_addr (base_struct_name=0x0, base_vaddr=0, ce=0x701370) at erase_info.c:1264
#5  update_filter_info (filter_symbol=0x701370, size_symbol=0x701430) at erase_info.c:1579
#6  0x0000000000416543 in process_config (config=<optimized out>) at erase_info.c:1789
#7  process_config_file (name_config=<optimized out>) at erase_info.c:1862
#8  0x0000000000417c57 in gather_filter_info () at erase_info.c:2356
#9  0x0000000000443ccb in create_dumpfile () at makedumpfile.c:9863

#10 0x000000000044561e in main (argc=<optimized out>, argv=<optimized out>) at makedumpfile.c:11342 (gdb)

Thanks,
Atsushi Kumagai

Quoted 44 lines

~Pratyush

Quoted 41 lines

Thanks,
Atsushi Kumagai

Quoted 36 lines

Hi All,

We came across another failure in makedumpfile when kaslr is enabled. This failure occurs when we try re-filtering. We try to erase some symbol from a dumpfile which was copied/compressed from /proc/vmcore using makedumpfile.

We have very limited symbol information in vmcoreinfo. So symbols to be erased may not be available in vmcoreinfo and we look for it in vmlinux. However, symbol address from vmlinux is a static address which differs from run time address with KASLR_OFFSET. Therefore, reading any "virtual address of vmlinux" from vmcore is not possible.

These patches finds runtime KASLR offset and then calculates run time address of symbols read from vmlinux.

Since, I am not an expert of x86, and these patches touch x86 part of makedumpfile, therefore I have CCed x86 experts. Please, provide your review comment and let me know if you think there could have been a better way to resolve this issue.

thanks

~Pratyush

Pratyush Anand (2):
makedumpfile: add runtime kaslr offset if it exists
x86_64: calculate page_offset in case of re-filtering

arch/x86_64.c  | 45 +++++++++++++++++++++++++++++++++++++++++++--
erase_info.c   |  1 +
makedumpfile.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
makedumpfile.h | 15 +++++++++++++++
4 files changed, 103 insertions(+), 2 deletions(-)

--
2.9.3

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Hi Atsushi,

Thanks for the testing.

Quoted 11 lines · Atsushi Kumagai

Quoted 10 lines

Hi Atsushi,

Quoted 4 lines · Atsushi Kumagai

Hello Pratyush,

Thanks for your report, I have received this.
I'm on vacation until Mar 8, I'll review it when I return from vacation.

Any further comment on it?
Otherwise, I will send a v2 after accommodating concern from Xunlei.

Quoted 3 lines

Unfortunately, it doesn't seem like I can make time anymore for review this week, but at least this patch doesn't seem to work in my environment (linux 4.8 without kaslr). Do you have any ideas ?

I see, why it would have caused. I have not tested this case, but I hope my v2 should not have this issue.

~Pratyush

Quoted 5 lines

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6be49f5 in fseek () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-13.el7.x86_64 elfutils-libelf-0.163-3.el7.x86_64

elfutils-libs-0.163-3.el7.x86_64 glibc-2.17-105.el7.x86_64 libgcc-4.8.5-4.el7.x86_64 libstdc++-4.8.5-4.el7.x86_64 snappy-1.1.0-3.el7.x86_64 xz-libs-5.1.2-12alpha.el7.x86_64 zlib-1.2.7-15.el7.x86_64

Quoted 71 lines

(gdb) bt

#0  0x00007ffff6be49f5 in fseek () from /lib64/libc.so.6
#1  0x0000000000429d38 in read_vmcoreinfo_symbol (str_symbol=0x44cb0c "SYMBOL(_stext)=") at makedumpfile.c:2384
#2  0x000000000042097a in get_kaslr_offset_x86_64 (vaddr=18446744071589596288) at arch/x86_64.c:45
#3  0x0000000000414310 in resolve_config_entry (ce=0x701370, base_vaddr=<optimized out>, base_struct_name=0x0)
    at erase_info.c:1091
#4  0x0000000000415a89 in get_config_symbol_addr (base_struct_name=0x0, base_vaddr=0, ce=0x701370) at erase_info.c:1264
#5  update_filter_info (filter_symbol=0x701370, size_symbol=0x701430) at erase_info.c:1579
#6  0x0000000000416543 in process_config (config=<optimized out>) at erase_info.c:1789
#7  process_config_file (name_config=<optimized out>) at erase_info.c:1862
#8  0x0000000000417c57 in gather_filter_info () at erase_info.c:2356
#9  0x0000000000443ccb in create_dumpfile () at makedumpfile.c:9863

#10 0x000000000044561e in main (argc=<optimized out>, argv=<optimized out>) at makedumpfile.c:11342 (gdb)

Thanks,
Atsushi Kumagai

Quoted 44 lines

~Pratyush

Quoted 41 lines

Thanks,
Atsushi Kumagai

Quoted 36 lines

Hi All,

We came across another failure in makedumpfile when kaslr is enabled. This failure occurs when we try re-filtering. We try to erase some symbol from a dumpfile which was copied/compressed from /proc/vmcore using makedumpfile.

We have very limited symbol information in vmcoreinfo. So symbols to be erased may not be available in vmcoreinfo and we look for it in vmlinux. However, symbol address from vmlinux is a static address which differs from run time address with KASLR_OFFSET. Therefore, reading any "virtual address of vmlinux" from vmcore is not possible.

These patches finds runtime KASLR offset and then calculates run time address of symbols read from vmlinux.

Since, I am not an expert of x86, and these patches touch x86 part of makedumpfile, therefore I have CCed x86 experts. Please, provide your review comment and let me know if you think there could have been a better way to resolve this issue.

thanks

~Pratyush

Pratyush Anand (2):
makedumpfile: add runtime kaslr offset if it exists
x86_64: calculate page_offset in case of re-filtering

arch/x86_64.c  | 45 +++++++++++++++++++++++++++++++++++++++++++--
erase_info.c   |  1 +
makedumpfile.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
makedumpfile.h | 15 +++++++++++++++
4 files changed, 103 insertions(+), 2 deletions(-)

--
2.9.3

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Quoted 20 lines

Hi Atsushi,

Thanks for the testing.

Quoted 14 lines · Atsushi Kumagai

Quoted 10 lines

Hi Atsushi,

Quoted 4 lines · Atsushi Kumagai

Hello Pratyush,

Thanks for your report, I have received this.
I'm on vacation until Mar 8, I'll review it when I return from vacation.

Any further comment on it?
Otherwise, I will send a v2 after accommodating concern from Xunlei.

Unfortunately, it doesn't seem like I can make time anymore for review this week, but at least this patch doesn't seem to work in my environment (linux 4.8 without kaslr). Do you have any ideas ?

Quoted 2 lines

I see, why it would have caused. I have not tested this case, but I hope my v2 should not have this issue.

Umm, v2 still doesn't work in my environment...
It seems that I have to investigate this deeper.

  $ cat scrub.conf
  [vmlinux]
  erase modules size 50
  $

  (gdb) r -cd31 -x vmlinux --config scrub.conf vmcore dumpfile.cd31
  Starting program: /work/kdump_utils/makedumpfile/makedumpfile -cd31 -x vmlinux --config scrub.conf vmcore dumpfile.cd31
  warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffd000
  [Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x000000308366ee0d in fseek () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.5-7.el6_0.x86_64 elfutils-libelf-0.152-1.el6.x86_64 elfutils-libs-0.152-1.el6.x86_64 glibc-2.12-1.132.el6.x86_64 libgcc-4.4.7-4.el6.x86_64 libstdc++-4.4.7-4.el6.x86_64 snappy-1.1.0-1.el6.x86_64 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-29.el6.x86_64 (gdb) bt

  #0  0x000000308366ee0d in fseek () from /lib64/libc.so.6
  #1  0x0000000000420937 in get_kaslr_offset_x86_64 (vaddr=18446744071589596288) at arch/x86_64.c:43
  #2  0x0000000000414310 in resolve_config_entry (ce=0x701370, base_vaddr=<value optimized out>, base_struct_name=0x0) at erase_info.c:1091
  #3  0x0000000000415a89 in get_config_symbol_addr (filter_symbol=0x701370, size_symbol=0x701430) at erase_info.c:1264
  #4  update_filter_info (filter_symbol=0x701370, size_symbol=0x701430) at erase_info.c:1579
  #5  0x0000000000416543 in process_config (name_config=<value optimized out>) at erase_info.c:1789
  #6  process_config_file (name_config=<value optimized out>) at erase_info.c:1862
  #7  0x0000000000417c57 in gather_filter_info () at erase_info.c:2356
  #8  0x0000000000443e5b in create_dumpfile () at makedumpfile.c:9870
  #9  0x00000000004457ae in main (argc=<value optimized out>, argv=<value optimized out>) at makedumpfile.c:11349

(gdb)

Thanks,
Atsushi Kuamgai

Quoted 79 lines

~Pratyush

Quoted 5 lines

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6be49f5 in fseek () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-13.el7.x86_64 elfutils-libelf-0.163-3.el7.x86_64

elfutils-libs-0.163-3.el7.x86_64 glibc-2.17-105.el7.x86_64 libgcc-4.8.5-4.el7.x86_64 libstdc++-4.8.5-4.el7.x86_64 snappy-1.1.0-3.el7.x86_64 xz-libs-5.1.2-12alpha.el7.x86_64 zlib-1.2.7-15.el7.x86_64

Quoted 71 lines

(gdb) bt

#0  0x00007ffff6be49f5 in fseek () from /lib64/libc.so.6
#1  0x0000000000429d38 in read_vmcoreinfo_symbol (str_symbol=0x44cb0c "SYMBOL(_stext)=") at makedumpfile.c:2384
#2  0x000000000042097a in get_kaslr_offset_x86_64 (vaddr=18446744071589596288) at arch/x86_64.c:45
#3  0x0000000000414310 in resolve_config_entry (ce=0x701370, base_vaddr=<optimized out>, base_struct_name=0x0)
    at erase_info.c:1091
#4  0x0000000000415a89 in get_config_symbol_addr (base_struct_name=0x0, base_vaddr=0, ce=0x701370) at erase_info.c:1264
#5  update_filter_info (filter_symbol=0x701370, size_symbol=0x701430) at erase_info.c:1579
#6  0x0000000000416543 in process_config (config=<optimized out>) at erase_info.c:1789
#7  process_config_file (name_config=<optimized out>) at erase_info.c:1862
#8  0x0000000000417c57 in gather_filter_info () at erase_info.c:2356
#9  0x0000000000443ccb in create_dumpfile () at makedumpfile.c:9863

#10 0x000000000044561e in main (argc=<optimized out>, argv=<optimized out>) at makedumpfile.c:11342 (gdb)

Thanks,
Atsushi Kumagai

Quoted 44 lines

~Pratyush

Quoted 41 lines

Thanks,
Atsushi Kumagai

Quoted 36 lines

Hi All,

We came across another failure in makedumpfile when kaslr is enabled. This failure occurs when we try re-filtering. We try to erase some symbol from a dumpfile which was copied/compressed from /proc/vmcore using makedumpfile.

We have very limited symbol information in vmcoreinfo. So symbols to be erased may not be available in vmcoreinfo and we look for it in vmlinux. However, symbol address from vmlinux is a static address which differs from run time address with KASLR_OFFSET. Therefore, reading any "virtual address of vmlinux" from vmcore is not possible.

These patches finds runtime KASLR offset and then calculates run time address of symbols read from vmlinux.

Since, I am not an expert of x86, and these patches touch x86 part of makedumpfile, therefore I have CCed x86 experts. Please, provide your review comment and let me know if you think there could have been a better way to resolve this issue.

thanks

~Pratyush

Pratyush Anand (2):
makedumpfile: add runtime kaslr offset if it exists
x86_64: calculate page_offset in case of re-filtering

arch/x86_64.c  | 45 +++++++++++++++++++++++++++++++++++++++++++--
erase_info.c   |  1 +
makedumpfile.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
makedumpfile.h | 15 +++++++++++++++
4 files changed, 103 insertions(+), 2 deletions(-)

--
2.9.3

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

Quoted 5 lines

Quoted 2 lines

Thanks for your report, I have received this.
I'm on vacation until Mar 8, I'll review it when I return from vacation.

Any further comment on it?
Otherwise, I will send a v2 after accommodating concern from Xunlei.

Unfortunately, it doesn't seem like I can make time anymore for review this week, but at least this patch doesn't seem to work in my environment (linux 4.8 without kaslr). Do you have any ideas ?

Quoted 5 lines

Quoted 2 lines

I see, why it would have caused. I have not tested this case, but I hope my v2 should not have this issue.

Umm, v2 still doesn't work in my environment...
It seems that I have to investigate this deeper.

Hummm, I thought we would see file_vmcoreinfo as NULL in get_kaslr_offset_x86_64() in your case. However, it's not true.

I think, it will have to be initialized with NULL in main().

Can you please try following fixup on top of this series:

makedumpfile.c +1 -0

index 57235690569e..0fd485ccd45d 100644
@@ -11076,6 +11076,7 @@ main(int argc, char *argv[])
                    strerror(errno));
                goto out;
        }
+       info->file_vmcoreinfo = NULL;
        info->fd_vmlinux = -1;
        info->fd_xen_syms = -1;
        info->fd_memory = -1;

Thanks for testing it thoroughly.

~Pratyush

Quoted 8 lines

  $ cat scrub.conf
  [vmlinux]
  erase modules size 50
  $

  (gdb) r -cd31 -x vmlinux --config scrub.conf vmcore dumpfile.cd31
  Starting program: /work/kdump_utils/makedumpfile/makedumpfile -cd31 -x vmlinux --config scrub.conf vmcore

dumpfile.cd31

Quoted 6 lines

warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffd000 [Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault. 0x000000308366ee0d in fseek () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.5-7.el6_0.x86_64

elfutils-libelf-0.152-1.el6.x86_64 elfutils-libs-0.152-1.el6.x86_64 glibc-2.12-1.132.el6.x86_64 libgcc-4.4.7-4.el6.x86_64 libstdc++-4.4.7-4.el6.x86_64 snappy-1.1.0-1.el6.x86_64 xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-29.el6.x86_64

Quoted 4 lines

(gdb) bt

  #0  0x000000308366ee0d in fseek () from /lib64/libc.so.6
  #1  0x0000000000420937 in get_kaslr_offset_x86_64 (vaddr=18446744071589596288) at arch/x86_64.c:43
  #2  0x0000000000414310 in resolve_config_entry (ce=0x701370, base_vaddr=<value optimized out>, base_struct_name=0x0)

at erase_info.c:1091

Quoted 7 lines

  #3  0x0000000000415a89 in get_config_symbol_addr (filter_symbol=0x701370, size_symbol=0x701430) at erase_info.c:1264
  #4  update_filter_info (filter_symbol=0x701370, size_symbol=0x701430) at erase_info.c:1579
  #5  0x0000000000416543 in process_config (name_config=<value optimized out>) at erase_info.c:1789
  #6  process_config_file (name_config=<value optimized out>) at erase_info.c:1862
  #7  0x0000000000417c57 in gather_filter_info () at erase_info.c:2356
  #8  0x0000000000443e5b in create_dumpfile () at makedumpfile.c:9870
  #9  0x00000000004457ae in main (argc=<value optimized out>, argv=<value optimized out>) at makedumpfile.c:11349

Quoted 11 lines

(gdb)

Thanks,
Atsushi Kuamgai

Quoted 6 lines

~Pratyush

Quoted 5 lines

Program received signal SIGSEGV, Segmentation fault. 0x00007ffff6be49f5 in fseek () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-13.el7.x86_64

elfutils-libelf-0.163-3.el7.x86_64

Quoted 9 lines

Quoted 9 lines

elfutils-libs-0.163-3.el7.x86_64 glibc-2.17-105.el7.x86_64 libgcc-4.8.5-4.el7.x86_64 libstdc++-4.8.5-4.el7.x86_64 snappy-1.1.0-3.el7.x86_64 xz-libs-5.1.2-12alpha.el7.x86_64 zlib-1.2.7-15.el7.x86_64

Quoted 7 lines

(gdb) bt

#0  0x00007ffff6be49f5 in fseek () from /lib64/libc.so.6
#1  0x0000000000429d38 in read_vmcoreinfo_symbol (str_symbol=0x44cb0c "SYMBOL(_stext)=") at makedumpfile.c:2384
#2  0x000000000042097a in get_kaslr_offset_x86_64 (vaddr=18446744071589596288) at arch/x86_64.c:45
#3  0x0000000000414310 in resolve_config_entry (ce=0x701370, base_vaddr=<optimized out>, base_struct_name=0x0)
    at erase_info.c:1091

#4 0x0000000000415a89 in get_config_symbol_addr (base_struct_name=0x0, base_vaddr=0, ce=0x701370) at

erase_info.c:1264

Quoted 67 lines

Quoted 59 lines

Quoted 59 lines

#5  update_filter_info (filter_symbol=0x701370, size_symbol=0x701430) at erase_info.c:1579
#6  0x0000000000416543 in process_config (config=<optimized out>) at erase_info.c:1789
#7  process_config_file (name_config=<optimized out>) at erase_info.c:1862
#8  0x0000000000417c57 in gather_filter_info () at erase_info.c:2356
#9  0x0000000000443ccb in create_dumpfile () at makedumpfile.c:9863

#10 0x000000000044561e in main (argc=<optimized out>, argv=<optimized out>) at makedumpfile.c:11342 (gdb)

Thanks,
Atsushi Kumagai

Quoted 44 lines

~Pratyush

Quoted 41 lines

Thanks,
Atsushi Kumagai

Quoted 36 lines

Hi All,

We came across another failure in makedumpfile when kaslr is enabled. This failure occurs when we try re-filtering. We try to erase some symbol from a dumpfile which was copied/compressed from /proc/vmcore using makedumpfile.

We have very limited symbol information in vmcoreinfo. So symbols to be erased may not be available in vmcoreinfo and we look for it in vmlinux. However, symbol address from vmlinux is a static address which differs from run time address with KASLR_OFFSET. Therefore, reading any "virtual address of vmlinux" from vmcore is not possible.

These patches finds runtime KASLR offset and then calculates run time address of symbols read from vmlinux.

Since, I am not an expert of x86, and these patches touch x86 part of makedumpfile, therefore I have CCed x86 experts. Please, provide your review comment and let me know if you think there could have been a better way to resolve this issue.

thanks

~Pratyush

Pratyush Anand (2):
makedumpfile: add runtime kaslr offset if it exists
x86_64: calculate page_offset in case of re-filtering

arch/x86_64.c  | 45 +++++++++++++++++++++++++++++++++++++++++++--
erase_info.c   |  1 +
makedumpfile.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
makedumpfile.h | 15 +++++++++++++++
4 files changed, 103 insertions(+), 2 deletions(-)

--
2.9.3

Quoted 5 lines

Quoted 5 lines

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Quoted 5 lines

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Quoted 16 lines

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

Quoted 5 lines

Quoted 2 lines

Thanks for your report, I have received this.
I'm on vacation until Mar 8, I'll review it when I return from vacation.

Any further comment on it?
Otherwise, I will send a v2 after accommodating concern from Xunlei.

Unfortunately, it doesn't seem like I can make time anymore for review this week, but at least this patch doesn't seem to work in my environment (linux 4.8 without kaslr). Do you have any ideas ?

Quoted 5 lines

Quoted 2 lines

I see, why it would have caused. I have not tested this case, but I hope my v2 should not have this issue.

Umm, v2 still doesn't work in my environment...
It seems that I have to investigate this deeper.

Quoted 6 lines

Hummm, I thought we would see file_vmcoreinfo as NULL in get_kaslr_offset_x86_64() in your case. However, it's not true.

I think, it will have to be initialized with NULL in main().

Can you please try following fixup on top of this series:

I found the cause, please see below:

initial()
+ find_kaslr_offsets()
+ open_vmcoreinfo()
+ get_kaslr_offset() // set info->kaslr_offset
+ close_vmcoreinfo()
gather_filter_info()
(snip)
+ resolve_config_entry()
+ get_kaslr_offset() // occur SIGSEGV since info->file_vmcoreinfo is closed

The cause code is in [PATCH v2 1/2],

erase_info.c +1 -0

index f2ba914..60abfa1 100644
@@ -1088,6 +1088,7 @@ resolve_config_entry(struct config_entry *ce, unsigned long long base_vaddr,
                                                        ce->line, ce->name);
                        return FALSE;
                }
+               ce->sym_addr += get_kaslr_offset(ce->sym_addr);
                ce->type_name = get_symbol_type_name(ce->name,
                                        DWARF_INFO_GET_SYMBOL_TYPE,
                                        &ce->size, &ce->type_flag);

I think we should use info->kaslr_offset instead of get_kaslr_offset(), how about you ?

BTW, I'm not sure why you didn't meet this issue...

Quoted 25 lines

Quoted 16 lines

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

Quoted 5 lines

Quoted 2 lines

Thanks for your report, I have received this.
I'm on vacation until Mar 8, I'll review it when I return from vacation.

Any further comment on it?
Otherwise, I will send a v2 after accommodating concern from Xunlei.

Unfortunately, it doesn't seem like I can make time anymore for review this week, but at least this patch doesn't seem to work in my environment (linux 4.8 without kaslr). Do you have any ideas ?

Quoted 5 lines

Quoted 2 lines

I see, why it would have caused. I have not tested this case, but I hope my v2 should not have this issue.

Umm, v2 still doesn't work in my environment...
It seems that I have to investigate this deeper.

Quoted 6 lines

Hummm, I thought we would see file_vmcoreinfo as NULL in get_kaslr_offset_x86_64() in your case. However, it's not true.

I think, it will have to be initialized with NULL in main().

Can you please try following fixup on top of this series:

I found the cause, please see below:

Quoted 9 lines

initial()
+ find_kaslr_offsets()
+ open_vmcoreinfo()
+ get_kaslr_offset() // set info->kaslr_offset
+ close_vmcoreinfo()
gather_filter_info()
(snip)
+ resolve_config_entry()
+ get_kaslr_offset() // occur SIGSEGV since info->file_vmcoreinfo is closed

Since info->file_vmcoreinfo is closed,therefore it should be NULL. But currently, close_vmcoreinfo() does not set it to NULL. We should also set info->file_vmcoreinfo to NULL in close_vmcoreinfo() apart from main().

Quoted 18 lines

The cause code is in [PATCH v2 1/2],

erase_info.c +1 -0

index f2ba914..60abfa1 100644
@@ -1088,6 +1088,7 @@ resolve_config_entry(struct config_entry *ce, unsigned long long base_vaddr,
                                                        ce->line, ce->name);
                        return FALSE;
                }
+               ce->sym_addr += get_kaslr_offset(ce->sym_addr);
                ce->type_name = get_symbol_type_name(ce->name,
                                        DWARF_INFO_GET_SYMBOL_TYPE,
                                        &ce->size, &ce->type_flag);

Quoted 2 lines

I think we should use info->kaslr_offset instead of get_kaslr_offset(), how about you ?

Actually, we are not sure at this point that ce->sym_addr is a kernel linear address. It could be a module address and that can have different randomization offset.

My intention is to calculate all types of kaslr offsets in find_kaslr_offsets() very early and then store them in different "info" elements. Now, whenever we call get_kaslr_offset() we would return right offset as per the input address.
I have very little idea about x86. So, I have left a TODO to calculate offset for non-linear addresses.

Quoted 1 line

Quoted 1 line

BTW, I'm not sure why you didn't meet this issue...

Because, I tested with kaslr kernel, so when get_kaslr_offset(ce->sym_addr) was called, I already had a valid info->kaslr_offset.

So, what about following fixup

makedumpfile.c +1 -0

index 57235690569e..4986d098d69a 100644
@@ -8685,6 +8685,7 @@ close_vmcoreinfo(void)
        if(fclose(info->file_vmcoreinfo) < 0)
                ERRMSG("Can't close the vmcoreinfo file(%s). %s\n",
                    info->name_vmcoreinfo, strerror(errno));
+       info->file_vmcoreinfo = NULL;
 }
 
 void

~Pratyush

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Quoted 36 lines · Atsushi Kumagai

Quoted 34 lines

Quoted 16 lines

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

Quoted 5 lines

Quoted 2 lines

Thanks for your report, I have received this.
I'm on vacation until Mar 8, I'll review it when I return from vacation.

Any further comment on it?
Otherwise, I will send a v2 after accommodating concern from Xunlei.

Unfortunately, it doesn't seem like I can make time anymore for review this week, but at least this patch doesn't seem to work in my environment (linux 4.8 without kaslr). Do you have any ideas ?

Quoted 5 lines

Quoted 2 lines

I see, why it would have caused. I have not tested this case, but I hope my v2 should not have this issue.

Umm, v2 still doesn't work in my environment...
It seems that I have to investigate this deeper.

Quoted 6 lines

Hummm, I thought we would see file_vmcoreinfo as NULL in get_kaslr_offset_x86_64() in your case. However, it's not true.

I think, it will have to be initialized with NULL in main().

Can you please try following fixup on top of this series:

I found the cause, please see below:

initial()
+ find_kaslr_offsets()
+ open_vmcoreinfo()
+ get_kaslr_offset() // set info->kaslr_offset
+ close_vmcoreinfo()
gather_filter_info()
(snip)
+ resolve_config_entry()
+ get_kaslr_offset() // occur SIGSEGV since info->file_vmcoreinfo is closed

Quoted 3 lines

Since info->file_vmcoreinfo is closed,therefore it should be NULL. But currently, close_vmcoreinfo() does not set it to NULL. We should also set info->file_vmcoreinfo to NULL in close_vmcoreinfo() apart from main().

Sure, uninitialized info->file_vmcoreinfo is a general issue, I'll fix it in another patch.

Quoted 19 lines

Quoted 19 lines

The cause code is in [PATCH v2 1/2],

erase_info.c +1 -0

index f2ba914..60abfa1 100644
@@ -1088,6 +1088,7 @@ resolve_config_entry(struct config_entry *ce, unsigned long long base_vaddr,
                                                        ce->line, ce->name);
                        return FALSE;
                }
+               ce->sym_addr += get_kaslr_offset(ce->sym_addr);
                ce->type_name = get_symbol_type_name(ce->name,
                                        DWARF_INFO_GET_SYMBOL_TYPE,
                                        &ce->size, &ce->type_flag);

Quoted 6 lines

Quoted 2 lines

I think we should use info->kaslr_offset instead of get_kaslr_offset(), how about you ?

Actually, we are not sure at this point that ce->sym_addr is a kernel linear address. It could be a module address and that can have different randomization offset.

I see, I misunderstood that the randomization offset is same in any case.

Quoted 8 lines

My intention is to calculate all types of kaslr offsets in find_kaslr_offsets() very early and then store them in different "info" elements. Now, whenever we call get_kaslr_offset() we would return right offset as per the input address.
I have very little idea about x86. So, I have left a TODO to calculate offset for non-linear addresses.

Quoted 1 line

Quoted 6 lines

Quoted 1 line

BTW, I'm not sure why you didn't meet this issue...

Because, I tested with kaslr kernel, so when get_kaslr_offset(ce->sym_addr) was called, I already had a valid info->kaslr_offset.

So, what about following fixup

As mentioned at the beginning, the fix below is not your fault, so I'll merge your patches as it is into v1.6.2.

Quoted 13 lines

makedumpfile.c +1 -0

index 57235690569e..4986d098d69a 100644
@@ -8685,6 +8685,7 @@ close_vmcoreinfo(void)
        if(fclose(info->file_vmcoreinfo) < 0)
                ERRMSG("Can't close the vmcoreinfo file(%s). %s\n",
                    info->name_vmcoreinfo, strerror(errno));
+       info->file_vmcoreinfo = NULL;
 }
 
 void

makedumpfile.c main(int argc, char *argv[]) · line 11083

Quoted 7 lines

makedumpfile.c +1 -0

@@ -11076,6 +11077,7 @@ main(int argc, char *argv[])
                    strerror(errno));
                goto out;
        }
+       info->file_vmcoreinfo = NULL;
        info->fd_vmlinux = -1;
        info->fd_xen_syms = -1;
        info->fd_memory = -1;

However, I think [PATCH 2/2] should be dropped since the alternative patch has appeared, is it ok with you ?

https://github.com/pratyushanand/makedumpfile/commit/16655ce1f4c2da8d4066072db2a03c84bf2553fe

Thanks,
Atsushi Kumagai

Quoted 7 lines

~Pratyush

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec