* [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled
@ 2017-04-27 6:15 Pratyush Anand
2017-04-27 6:15 ` [Makedumpfile PATCH 1/2] makedumpfile: add runtime kaslr offset if it exists Pratyush Anand
` (3 more replies)
0 siblings, 4 replies; 16+ messages in thread
From: Pratyush Anand @ 2017-04-27 6:15 UTC (permalink / raw)
To: ats-kumagai; +Cc: Pratyush Anand, keescook, bhe, dyoung, kexec, yinghai, mingo
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
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 16+ messages in thread* [Makedumpfile PATCH 1/2] makedumpfile: add runtime kaslr offset if it exists 2017-04-27 6:15 [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled Pratyush Anand @ 2017-04-27 6:15 ` Pratyush Anand 2017-04-28 5:40 ` Xunlei Pang 2017-04-27 6:15 ` [Makedumpfile PATCH 2/2] x86_64: calculate page_offset in case of re-filtering Pratyush Anand ` (2 subsequent siblings) 3 siblings, 1 reply; 16+ messages in thread From: Pratyush Anand @ 2017-04-27 6:15 UTC (permalink / raw) To: ats-kumagai; +Cc: Pratyush Anand, keescook, bhe, dyoung, kexec, yinghai, mingo 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 <panand@redhat.com> --- arch/x86_64.c | 23 +++++++++++++++++++++++ erase_info.c | 1 + makedumpfile.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ makedumpfile.h | 15 +++++++++++++++ 4 files changed, 83 insertions(+) diff --git a/arch/x86_64.c b/arch/x86_64.c index e978a36f8878..ab5aae8f1b26 100644 --- a/arch/x86_64.c +++ b/arch/x86_64.c @@ -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) { diff --git a/erase_info.c b/erase_info.c index f2ba9149e93e..60abfa1a1adf 100644 --- a/erase_info.c +++ b/erase_info.c @@ -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); diff --git a/makedumpfile.c b/makedumpfile.c index 301772a8820c..7e78641917d7 100644 --- a/makedumpfile.c +++ b/makedumpfile.c @@ -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; + + unlink(info->name_vmcoreinfo); + + /* + * This arch specific function should update info->kaslr_offset. If + * kaslr is not enabled then offset will be set to 0. arch specific + * function might need to read from vmcoreinfo, therefore we have + * called this function between open_vmcoreinfo() and + * close_vmcoreinfo() + */ + get_kaslr_offset(SYMBOL(_stext)); + + 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(); /* diff --git a/makedumpfile.h b/makedumpfile.h index e32e567018f6..0d358be8caac 100644 --- a/makedumpfile.h +++ b/makedumpfile.h @@ -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 @@ -1803,6 +1817,7 @@ struct memory_range { struct memory_range crash_reserved_mem[CRASH_RESERVED_MEM_NR]; int crash_reserved_mem_nr; +unsigned long read_vmcoreinfo_symbol(char *str_symbol); int readmem(int type_addr, unsigned long long addr, void *bufptr, size_t size); int get_str_osrelease_from_vmlinux(void); int read_vmcoreinfo_xen(void); -- 2.9.3 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [Makedumpfile PATCH 1/2] makedumpfile: add runtime kaslr offset if it exists 2017-04-27 6:15 ` [Makedumpfile PATCH 1/2] makedumpfile: add runtime kaslr offset if it exists Pratyush Anand @ 2017-04-28 5:40 ` Xunlei Pang 2017-04-28 6:00 ` Pratyush Anand 0 siblings, 1 reply; 16+ messages in thread From: Xunlei Pang @ 2017-04-28 5:40 UTC (permalink / raw) To: Pratyush Anand, ats-kumagai; +Cc: keescook, bhe, dyoung, kexec, yinghai, mingo On 04/27/2017 at 02:15 PM, Pratyush Anand wrote: > 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 <panand@redhat.com> > --- > arch/x86_64.c | 23 +++++++++++++++++++++++ > erase_info.c | 1 + > makedumpfile.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ > makedumpfile.h | 15 +++++++++++++++ > 4 files changed, 83 insertions(+) > > diff --git a/arch/x86_64.c b/arch/x86_64.c > index e978a36f8878..ab5aae8f1b26 100644 > --- a/arch/x86_64.c > +++ b/arch/x86_64.c > @@ -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) > { > diff --git a/erase_info.c b/erase_info.c > index f2ba9149e93e..60abfa1a1adf 100644 > --- a/erase_info.c > +++ b/erase_info.c > @@ -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); > diff --git a/makedumpfile.c b/makedumpfile.c > index 301772a8820c..7e78641917d7 100644 > --- a/makedumpfile.c > +++ b/makedumpfile.c > @@ -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; > + > + unlink(info->name_vmcoreinfo); > + > + /* > + * This arch specific function should update info->kaslr_offset. If > + * kaslr is not enabled then offset will be set to 0. arch specific > + * function might need to read from vmcoreinfo, therefore we have > + * called this function between open_vmcoreinfo() and > + * close_vmcoreinfo() > + */ > + 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());" Regards, Xunlei > + > + 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(); > > /* > diff --git a/makedumpfile.h b/makedumpfile.h > index e32e567018f6..0d358be8caac 100644 > --- a/makedumpfile.h > +++ b/makedumpfile.h > @@ -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 > @@ -1803,6 +1817,7 @@ struct memory_range { > struct memory_range crash_reserved_mem[CRASH_RESERVED_MEM_NR]; > int crash_reserved_mem_nr; > > +unsigned long read_vmcoreinfo_symbol(char *str_symbol); > int readmem(int type_addr, unsigned long long addr, void *bufptr, size_t size); > int get_str_osrelease_from_vmlinux(void); > int read_vmcoreinfo_xen(void); _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Makedumpfile PATCH 1/2] makedumpfile: add runtime kaslr offset if it exists 2017-04-28 5:40 ` Xunlei Pang @ 2017-04-28 6:00 ` Pratyush Anand 0 siblings, 0 replies; 16+ messages in thread From: Pratyush Anand @ 2017-04-28 6:00 UTC (permalink / raw) To: xlpang, ats-kumagai; +Cc: keescook, bhe, dyoung, kexec, yinghai, mingo On Friday 28 April 2017 11:10 AM, Xunlei Pang wrote: >> + */ >> + get_kaslr_offset(SYMBOL(_stext)); > Looks like acquiring "KERNELOFFSET" in read_vmcoreinfo() should be enough here. Ah..OK..but may be not here..rather in get_kaslr_offset_x86_64() would be better. Not all arch could export this offset. > > 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());" ~Pratyush _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Makedumpfile PATCH 2/2] x86_64: calculate page_offset in case of re-filtering 2017-04-27 6:15 [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled Pratyush Anand 2017-04-27 6:15 ` [Makedumpfile PATCH 1/2] makedumpfile: add runtime kaslr offset if it exists Pratyush Anand @ 2017-04-27 6:15 ` Pratyush Anand 2017-04-28 6:26 ` [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled Baoquan He 2017-04-28 6:52 ` Atsushi Kumagai 3 siblings, 0 replies; 16+ messages in thread From: Pratyush Anand @ 2017-04-27 6:15 UTC (permalink / raw) To: ats-kumagai; +Cc: Pratyush Anand, keescook, bhe, dyoung, kexec, yinghai, mingo we do not call get_elf_info() in case of refiltering. Therefore, we will not have any pt_load in that case, and so we get: get_page_offset_x86_64: Can't get any pt_load to calculate page offset. However, we will have vmcoreinfo and vmlinux information in case of re-filtering. So, we are able to find kaslr offset and we can get page_offset_base address. Thus we can read the page offset as well. However, if kaslr is not enabled then use old method to find fixed page offset. Signed-off-by: Pratyush Anand <panand@redhat.com> --- arch/x86_64.c | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/arch/x86_64.c b/arch/x86_64.c index ab5aae8f1b26..b38ba2479d3d 100644 --- a/arch/x86_64.c +++ b/arch/x86_64.c @@ -62,6 +62,7 @@ get_page_offset_x86_64(void) int i; unsigned long long phys_start; unsigned long long virt_start; + unsigned long page_offset_base; for (i = 0; get_pt_load(i, &phys_start, NULL, &virt_start, NULL); i++) { if (virt_start < __START_KERNEL_map @@ -71,8 +72,25 @@ get_page_offset_x86_64(void) } } - ERRMSG("Can't get any pt_load to calculate page offset.\n"); - return FALSE; + if (!info->flag_refiltering) { + ERRMSG("Can't get any pt_load to calculate page offset.\n"); + return FALSE; + } + if (info->kaslr_offset) { + page_offset_base = get_symbol_addr("page_offset_base"); + page_offset_base += info->kaslr_offset; + if (!readmem(VADDR, page_offset_base, &info->page_offset, + sizeof(info->page_offset))) { + ERRMSG("Can't read page_offset_base.\n"); + return FALSE; + } + } else if (info->kernel_version < KERNEL_VERSION(2, 6, 27)) { + info->page_offset = __PAGE_OFFSET_ORIG; + } else { + info->page_offset = __PAGE_OFFSET_2_6_27; + } + + return TRUE; } int -- 2.9.3 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled 2017-04-27 6:15 [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled Pratyush Anand 2017-04-27 6:15 ` [Makedumpfile PATCH 1/2] makedumpfile: add runtime kaslr offset if it exists Pratyush Anand 2017-04-27 6:15 ` [Makedumpfile PATCH 2/2] x86_64: calculate page_offset in case of re-filtering Pratyush Anand @ 2017-04-28 6:26 ` Baoquan He 2017-04-28 6:52 ` Atsushi Kumagai 3 siblings, 0 replies; 16+ messages in thread From: Baoquan He @ 2017-04-28 6:26 UTC (permalink / raw) To: Pratyush Anand; +Cc: keescook, dyoung, ats-kumagai, kexec, yinghai, mingo Usually we can use gdb to debug the running kernel like this: gdb vmlinux /proc/kcore However now it doesn't work any more since those kernel symbols are got at compiling time, while kaslr-ed kernel do relocation on them. Don't know if this will impact anything else. On 04/27/17 at 11:45am, Pratyush Anand wrote: > 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 > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled 2017-04-27 6:15 [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled Pratyush Anand ` (2 preceding siblings ...) 2017-04-28 6:26 ` [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled Baoquan He @ 2017-04-28 6:52 ` Atsushi Kumagai 2017-05-09 13:22 ` Pratyush Anand 3 siblings, 1 reply; 16+ messages in thread From: Atsushi Kumagai @ 2017-04-28 6:52 UTC (permalink / raw) To: Pratyush Anand Cc: keescook@chromium.org, bhe@redhat.com, dyoung@redhat.com, kexec@lists.infradead.org, yinghai@kernel.org, mingo@kernel.org 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 >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 kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled 2017-04-28 6:52 ` Atsushi Kumagai @ 2017-05-09 13:22 ` Pratyush Anand 2017-05-10 8:07 ` Atsushi Kumagai 0 siblings, 1 reply; 16+ messages in thread From: Pratyush Anand @ 2017-05-09 13:22 UTC (permalink / raw) To: Atsushi Kumagai Cc: keescook@chromium.org, bhe@redhat.com, dyoung@redhat.com, kexec@lists.infradead.org, Xunlei Pang, yinghai@kernel.org, mingo@kernel.org Hi Atsushi, On Friday 28 April 2017 12:22 PM, Atsushi Kumagai wrote: > 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 > > Thanks, > Atsushi Kumagai > >> 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 kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled 2017-05-09 13:22 ` Pratyush Anand @ 2017-05-10 8:07 ` Atsushi Kumagai 2017-05-12 2:43 ` Pratyush Anand 0 siblings, 1 reply; 16+ messages in thread From: Atsushi Kumagai @ 2017-05-10 8:07 UTC (permalink / raw) To: Pratyush Anand Cc: keescook@chromium.org, bhe@redhat.com, dyoung@redhat.com, kexec@lists.infradead.org, Xunlei Pang, yinghai@kernel.org, mingo@kernel.org >Hi Atsushi, > >On Friday 28 April 2017 12:22 PM, Atsushi Kumagai wrote: >> 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 ? 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 >~Pratyush > > >> >> Thanks, >> Atsushi Kumagai >> >>> 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 kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled 2017-05-10 8:07 ` Atsushi Kumagai @ 2017-05-12 2:43 ` Pratyush Anand 2017-05-16 2:05 ` Atsushi Kumagai 0 siblings, 1 reply; 16+ messages in thread From: Pratyush Anand @ 2017-05-12 2:43 UTC (permalink / raw) To: Atsushi Kumagai Cc: keescook@chromium.org, bhe@redhat.com, kexec@lists.infradead.org, dyoung@redhat.com, Xunlei Pang, yinghai@kernel.org, mingo@kernel.org Hi Atsushi, Thanks for the testing. On Wednesday 10 May 2017 01:37 PM, Atsushi Kumagai wrote: >> Hi Atsushi, >> >> On Friday 28 April 2017 12:22 PM, Atsushi Kumagai wrote: >>> 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 ? I see, why it would have caused. I have not tested this case, but I hope my v2 should not have this issue. ~Pratyush > > > 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 > >> ~Pratyush >> >> >>> >>> Thanks, >>> Atsushi Kumagai >>> >>>> 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 > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 16+ messages in thread
* RE: [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled 2017-05-12 2:43 ` Pratyush Anand @ 2017-05-16 2:05 ` Atsushi Kumagai 2017-05-22 7:56 ` Pratyush Anand 0 siblings, 1 reply; 16+ messages in thread From: Atsushi Kumagai @ 2017-05-16 2:05 UTC (permalink / raw) To: Pratyush Anand Cc: keescook@chromium.org, bhe@redhat.com, kexec@lists.infradead.org, dyoung@redhat.com, Xunlei Pang, yinghai@kernel.org, mingo@kernel.org >Hi Atsushi, > >Thanks for the testing. > >On Wednesday 10 May 2017 01:37 PM, Atsushi Kumagai wrote: >>> Hi Atsushi, >>> >>> On Friday 28 April 2017 12:22 PM, Atsushi Kumagai wrote: >>>> 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 ? > >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 >~Pratyush >> >> >> 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 >> >>> ~Pratyush >>> >>> >>>> >>>> Thanks, >>>> Atsushi Kumagai >>>> >>>>> 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 >> kexec@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/kexec >> _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled 2017-05-16 2:05 ` Atsushi Kumagai @ 2017-05-22 7:56 ` Pratyush Anand 2017-05-23 3:09 ` Atsushi Kumagai 0 siblings, 1 reply; 16+ messages in thread From: Pratyush Anand @ 2017-05-22 7:56 UTC (permalink / raw) To: Atsushi Kumagai Cc: keescook@chromium.org, bhe@redhat.com, yinghai@kernel.org, Xunlei Pang, mingo@kernel.org, dyoung@redhat.com, kexec@lists.infradead.org On Tuesday 16 May 2017 07:35 AM, Atsushi Kumagai wrote: >> Hi Atsushi, >> >> Thanks for the testing. >> >> On Wednesday 10 May 2017 01:37 PM, Atsushi Kumagai wrote: >>>> Hi Atsushi, >>>> >>>> On Friday 28 April 2017 12:22 PM, Atsushi Kumagai wrote: >>>>> 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 ? >> >> 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: diff --git a/makedumpfile.c b/makedumpfile.c index 57235690569e..0fd485ccd45d 100644 --- a/makedumpfile.c +++ b/makedumpfile.c @@ -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 > > $ 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 > >> ~Pratyush >>> >>> >>> 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 >>> >>>> ~Pratyush >>>> >>>> >>>>> >>>>> Thanks, >>>>> Atsushi Kumagai >>>>> >>>>>> 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 >>> kexec@lists.infradead.org >>> http://lists.infradead.org/mailman/listinfo/kexec >>> > > > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply related [flat|nested] 16+ messages in thread
* RE: [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled 2017-05-22 7:56 ` Pratyush Anand @ 2017-05-23 3:09 ` Atsushi Kumagai 2017-05-23 3:57 ` Pratyush Anand 0 siblings, 1 reply; 16+ messages in thread From: Atsushi Kumagai @ 2017-05-23 3:09 UTC (permalink / raw) To: Pratyush Anand Cc: keescook@chromium.org, bhe@redhat.com, yinghai@kernel.org, Xunlei Pang, kexec@lists.infradead.org, dyoung@redhat.com, mingo@kernel.org >>>>>> 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 ? >>> >>> 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: 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], diff --git a/erase_info.c b/erase_info.c index f2ba914..60abfa1 100644 --- a/erase_info.c +++ b/erase_info.c @@ -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... Thanks, Atsushi Kumagai >diff --git a/makedumpfile.c b/makedumpfile.c >index 57235690569e..0fd485ccd45d 100644 >--- a/makedumpfile.c >+++ b/makedumpfile.c >@@ -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 > >> >> $ 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 >> >>> ~Pratyush >>>> >>>> >>>> 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 >>>> >>>>> ~Pratyush >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Atsushi Kumagai >>>>>> >>>>>>> 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 >>>> kexec@lists.infradead.org >>>> http://lists.infradead.org/mailman/listinfo/kexec >>>> >> >> >> >> _______________________________________________ >> kexec mailing list >> kexec@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/kexec >> > >_______________________________________________ >kexec mailing list >kexec@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/kexec _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled 2017-05-23 3:09 ` Atsushi Kumagai @ 2017-05-23 3:57 ` Pratyush Anand 2017-05-24 6:11 ` Atsushi Kumagai 0 siblings, 1 reply; 16+ messages in thread From: Pratyush Anand @ 2017-05-23 3:57 UTC (permalink / raw) To: Atsushi Kumagai Cc: keescook@chromium.org, bhe@redhat.com, yinghai@kernel.org, Xunlei Pang, mingo@kernel.org, dyoung@redhat.com, kexec@lists.infradead.org Hi Atsushi, Thanks a lot for testing it. On Tuesday 23 May 2017 08:39 AM, Atsushi Kumagai wrote: >>>>>>> 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 ? >>>> >>>> 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: > > 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 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(). > > > The cause code is in [PATCH v2 1/2], > > diff --git a/erase_info.c b/erase_info.c > index f2ba914..60abfa1 100644 > --- a/erase_info.c > +++ b/erase_info.c > @@ -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 ? 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. > > 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 diff --git a/makedumpfile.c b/makedumpfile.c index 57235690569e..4986d098d69a 100644 --- a/makedumpfile.c +++ b/makedumpfile.c @@ -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 @@ -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; ~Pratyush _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply related [flat|nested] 16+ messages in thread
* RE: [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled 2017-05-23 3:57 ` Pratyush Anand @ 2017-05-24 6:11 ` Atsushi Kumagai 2017-05-24 6:28 ` Pratyush Anand 0 siblings, 1 reply; 16+ messages in thread From: Atsushi Kumagai @ 2017-05-24 6:11 UTC (permalink / raw) To: Pratyush Anand Cc: keescook@chromium.org, bhe@redhat.com, yinghai@kernel.org, Xunlei Pang, kexec@lists.infradead.org, dyoung@redhat.com, mingo@kernel.org >On Tuesday 23 May 2017 08:39 AM, Atsushi Kumagai wrote: >>>>>>>> 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 ? >>>>> >>>>> 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: >> >> 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 > >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. >> >> >> The cause code is in [PATCH v2 1/2], >> >> diff --git a/erase_info.c b/erase_info.c >> index f2ba914..60abfa1 100644 >> --- a/erase_info.c >> +++ b/erase_info.c >> @@ -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 ? > >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. >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. > >> >> 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. >diff --git a/makedumpfile.c b/makedumpfile.c >index 57235690569e..4986d098d69a 100644 >--- a/makedumpfile.c >+++ b/makedumpfile.c >@@ -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 >@@ -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 > >~Pratyush > >_______________________________________________ >kexec mailing list >kexec@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/kexec _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled 2017-05-24 6:11 ` Atsushi Kumagai @ 2017-05-24 6:28 ` Pratyush Anand 0 siblings, 0 replies; 16+ messages in thread From: Pratyush Anand @ 2017-05-24 6:28 UTC (permalink / raw) To: Atsushi Kumagai Cc: keescook@chromium.org, bhe@redhat.com, yinghai@kernel.org, Xunlei Pang, mingo@kernel.org, Hatayama, Daisuke, dyoung@redhat.com, kexec@lists.infradead.org On Wednesday 24 May 2017 11:41 AM, Atsushi Kumagai wrote: >> On Tuesday 23 May 2017 08:39 AM, Atsushi Kumagai wrote: >>>>>>>>> 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 ? >>>>>> >>>>>> 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: >>> >>> 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 >> >> 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. I will be sending v2 today which should also fix issue seen by Hatayama, Daisuke. http://lists.infradead.org/pipermail/kexec/2017-May/018833.html ~Pratyush > >>> >>> >>> The cause code is in [PATCH v2 1/2], >>> >>> diff --git a/erase_info.c b/erase_info.c >>> index f2ba914..60abfa1 100644 >>> --- a/erase_info.c >>> +++ b/erase_info.c >>> @@ -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 ? >> >> 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. > >> 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. >> >>> >>> 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. > >> diff --git a/makedumpfile.c b/makedumpfile.c >> index 57235690569e..4986d098d69a 100644 >> --- a/makedumpfile.c >> +++ b/makedumpfile.c >> @@ -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 >> @@ -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 > >> >> ~Pratyush >> >> _______________________________________________ >> kexec mailing list >> kexec@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/kexec > > > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2017-05-24 6:29 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-04-27 6:15 [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled Pratyush Anand 2017-04-27 6:15 ` [Makedumpfile PATCH 1/2] makedumpfile: add runtime kaslr offset if it exists Pratyush Anand 2017-04-28 5:40 ` Xunlei Pang 2017-04-28 6:00 ` Pratyush Anand 2017-04-27 6:15 ` [Makedumpfile PATCH 2/2] x86_64: calculate page_offset in case of re-filtering Pratyush Anand 2017-04-28 6:26 ` [Makedumpfile PATCH 0/2] Fix refiltering when kaslr enabled Baoquan He 2017-04-28 6:52 ` Atsushi Kumagai 2017-05-09 13:22 ` Pratyush Anand 2017-05-10 8:07 ` Atsushi Kumagai 2017-05-12 2:43 ` Pratyush Anand 2017-05-16 2:05 ` Atsushi Kumagai 2017-05-22 7:56 ` Pratyush Anand 2017-05-23 3:09 ` Atsushi Kumagai 2017-05-23 3:57 ` Pratyush Anand 2017-05-24 6:11 ` Atsushi Kumagai 2017-05-24 6:28 ` Pratyush Anand
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.