In kernel v4.6, Kernel ASLR (KASLR) is supported on arm64, and the start address of the kernel image can be randomized if CONFIG_RANDOMIZE_BASE is enabled. Even worse, the kernel image is no more mapped in the linear mapping, but in vmalloc area (i.e. below PAGE_OFFSET). Now, according to the kernel's memory.h, converting a virtual address to a physical address should be done like below: phys_addr_t __x = (phys_addr_t)(x); \ __x & BIT(VA_BITS - 1) ? (__x & ~PAGE_OFFSET) + PHYS_OFFSET : \ (__x - kimage_voffset); }) Please note that PHYS_OFFSET is no more equal to the start address of the first usable memory block in SYSTEM RAM due to the fact mentioned above. This patch addresses this change and allows the crash utility to access memory contents with correct addresses. * On a live system, crash with this patch won't work, especially with CONFIG_RANDOMIZE_RAM configured, because we currently have no way to know kimage_voffset. * For a core dump file, we can do simply: $ crash <vmlinux> <vmcore> as long as the file has "NUMBER(kimage_voffset)" (RELOC_AUTO|KASLR is automatically set.) I'm planning to add this enhancement in my next version of kexec/kdump patch, i.e. v17. Signed-off-by: AKASHI Takahiro <takahiro.akashi(a)linaro.org&gt; --- arm64.c | 218 ++++++++++++++++++++++++++++++++++++++++++++++++-------------- defs.h | 24 +++++-- main.c | 7 +- symbols.c | 12 ++-- 4 files changed, 197 insertions(+), 64 deletions(-) diff --git a/arm64.c b/arm64.c index 34c8c59..c16ea67 100644 --- a/arm64.c +++ b/arm64.c @@ -72,6 +72,21 @@ static int arm64_get_crash_notes(void); static void arm64_calc_VA_BITS(void); static int arm64_is_uvaddr(ulong, struct task_context *); +ulong +arm64_VTOP(ulong addr) +{ + if (!(machdep->flags & NEW_VMEMMAP) || + (addr >= machdep->machspec->page_offset)) { + return machdep->machspec->phys_offset + + (addr - machdep->machspec->page_offset); + } else { + if (machdep->machspec->kimage_voffset) + return addr - machdep->machspec->kimage_voffset; + else /* no randomness */ + return machdep->machspec->phys_offset + + (addr - machdep->machspec->vmalloc_start_addr); + } +} /* * Do all necessary machine-specific setup here. This is called several times @@ -81,6 +96,7 @@ void arm64_init(int when) { ulong value; + char *string; struct machine_specific *ms; #if defined(__x86_64__) @@ -102,9 +118,33 @@ arm64_init(int when) if (machdep->cmdline_args[0]) arm64_parse_cmdline_args(); machdep->flags |= MACHDEP_BT_TEXT; + + ms = machdep->machspec; + if (!ms->kimage_voffset && + (string = pc->read_vmcoreinfo("NUMBER(kimage_voffset)"))) { + ms->kimage_voffset = htol(string, QUIET, NULL); + free(string); + } + + if (ms->kimage_voffset) { + machdep->flags |= NEW_VMEMMAP; + + /* + * Even if CONFIG_RANDOMIZE_RAM is not configured, + * derive_kaslr_offset() should work and set + * kt->relocate to 0 + */ + if (!kt->relocate && !(kt->flags2 & (RELOC_AUTO|KASLR))) + kt->flags2 |= (RELOC_AUTO|KASLR); + } + break; case PRE_GDB: + /* This check is somewhat redundant */ + if (kernel_symbol_exists("kimage_voffset")) + machdep->flags |= NEW_VMEMMAP; + if (!machdep->pagesize) { /* * Kerneldoc Documentation/arm64/booting.txt describes @@ -160,16 +200,35 @@ arm64_init(int when) machdep->pagemask = ~((ulonglong)machdep->pageoffset); arm64_calc_VA_BITS(); - machdep->machspec->page_offset = ARM64_PAGE_OFFSET; + ms = machdep->machspec; + ms->page_offset = ARM64_PAGE_OFFSET; + /* FIXME: idmap for NEW_VMEMMAP */ machdep->identity_map_base = ARM64_PAGE_OFFSET; - machdep->machspec->userspace_top = ARM64_USERSPACE_TOP; - machdep->machspec->modules_vaddr = ARM64_MODULES_VADDR; - machdep->machspec->modules_end = ARM64_MODULES_END; - machdep->machspec->vmalloc_start_addr = ARM64_VMALLOC_START; - machdep->machspec->vmalloc_end = ARM64_VMALLOC_END; - machdep->kvbase = ARM64_VMALLOC_START; - machdep->machspec->vmemmap_vaddr = ARM64_VMEMMAP_VADDR; - machdep->machspec->vmemmap_end = ARM64_VMEMMAP_END; + machdep->kvbase = ARM64_VA_START; + ms->userspace_top = ARM64_USERSPACE_TOP; + if (machdep->flags & NEW_VMEMMAP) { + struct syment *sp; + + sp = kernel_symbol_search("_text"); + ms->kimage_text = (sp ? sp->value : 0); + sp = kernel_symbol_search("_end"); + ms->kimage_end = (sp ? sp->value : 0); + + ms->modules_vaddr = ARM64_VA_START; + if (kernel_symbol_exists("kasan_init")) + ms->modules_vaddr += ARM64_KASAN_SHADOW_SIZE; + ms->modules_end = ms->modules_vaddr + + ARM64_MODULES_VSIZE -1; + + ms->vmalloc_start_addr = ms->modules_end + 1; + } else { + ms->modules_vaddr = ARM64_PAGE_OFFSET - MEGABYTES(64); + ms->modules_end = ARM64_PAGE_OFFSET - 1; + ms->vmalloc_start_addr = ARM64_VA_START; + } + ms->vmalloc_end = ARM64_VMALLOC_END; + ms->vmemmap_vaddr = ARM64_VMEMMAP_VADDR; + ms->vmemmap_end = ARM64_VMEMMAP_END; switch (machdep->pagesize) { @@ -232,8 +291,6 @@ arm64_init(int when) machdep->stacksize = ARM64_STACK_SIZE; machdep->flags |= VMEMMAP; - arm64_calc_phys_offset(); - machdep->uvtop = arm64_uvtop; machdep->kvtop = arm64_kvtop; machdep->is_kvaddr = generic_is_kvaddr; @@ -262,6 +319,10 @@ arm64_init(int when) machdep->dumpfile_init = NULL; machdep->verify_line_number = NULL; machdep->init_kernel_pgd = arm64_init_kernel_pgd; + + /* use machdep parameters */ + arm64_calc_phys_offset(); + break; case POST_GDB: @@ -409,6 +470,8 @@ arm64_dump_machdep_table(ulong arg) fprintf(fp, "%sIRQ_STACKS", others++ ? "|" : ""); if (machdep->flags & MACHDEP_BT_TEXT) fprintf(fp, "%sMACHDEP_BT_TEXT", others++ ? "|" : ""); + if (machdep->flags & NEW_VMEMMAP) + fprintf(fp, "%sNEW_VMEMMAP", others++ ? "|" : ""); fprintf(fp, ")\n"); fprintf(fp, " kvbase: %lx\n", machdep->kvbase); @@ -503,6 +566,11 @@ arm64_dump_machdep_table(ulong arg) fprintf(fp, " modules_end: %016lx\n", ms->modules_end); fprintf(fp, " vmemmap_vaddr: %016lx\n", ms->vmemmap_vaddr); fprintf(fp, " vmemmap_end: %016lx\n", ms->vmemmap_end); + if (machdep->flags & NEW_VMEMMAP) { + fprintf(fp, " kimage_text: %016lx\n", ms->kimage_text); + fprintf(fp, " kimage_end: %016lx\n", ms->kimage_end); + fprintf(fp, " kimage_voffset: %016lx\n", ms->kimage_voffset); + } fprintf(fp, " phys_offset: %lx\n", ms->phys_offset); fprintf(fp, "__exception_text_start: %lx\n", ms->__exception_text_start); fprintf(fp, " __exception_text_end: %lx\n", ms->__exception_text_end); @@ -543,6 +611,42 @@ arm64_dump_machdep_table(ulong arg) } } +static int +arm64_parse_machdep_arg_l(char *argstring, char *param, ulong *value) +{ + int len; + int megabytes = FALSE; + char *p; + + len = strlen(param); + if (!STRNEQ(argstring, param) || (argstring[len] != '=')) + return FALSE; + + if ((LASTCHAR(argstring) == 'm') || + (LASTCHAR(argstring) == 'M')) { + LASTCHAR(argstring) = NULLCHAR; + megabytes = TRUE; + } + + p = argstring + len + 1; + if (strlen(p)) { + int flags = RETURN_ON_ERROR | QUIET; + int err = 0; + + if (megabytes) { + *value = dtol(p, flags, &err); + if (!err) + *value = MEGABYTES(*value); + } else { + *value = htol(p, flags, &err); + } + + if (!err) + return TRUE; + } + + return FALSE; +} /* * Parse machine dependent command line arguments. @@ -554,11 +658,10 @@ arm64_dump_machdep_table(ulong arg) static void arm64_parse_cmdline_args(void) { - int index, i, c, err; + int index, i, c; char *arglist[MAXARGS]; char buf[BUFSIZE]; char *p; - ulong value = 0; for (index = 0; index < MAX_MACHDEP_ARGS; index++) { if (!machdep->cmdline_args[index]) @@ -580,39 +683,23 @@ arm64_parse_cmdline_args(void) c = parse_line(buf, arglist); for (i = 0; i < c; i++) { - err = 0; - - if (STRNEQ(arglist[i], "phys_offset=")) { - int megabytes = FALSE; - int flags = RETURN_ON_ERROR | QUIET; - - if ((LASTCHAR(arglist[i]) == 'm') || - (LASTCHAR(arglist[i]) == 'M')) { - LASTCHAR(arglist[i]) = NULLCHAR; - megabytes = TRUE; - } - - p = arglist[i] + strlen("phys_offset="); - if (strlen(p)) { - if (megabytes) - value = dtol(p, flags, &err); - else - value = htol(p, flags, &err); - } - - if (!err) { - if (megabytes) - value = MEGABYTES(value); - - machdep->machspec->phys_offset = value; - - error(NOTE, - "setting phys_offset to: 0x%lx\n\n", - machdep->machspec->phys_offset); + if (arm64_parse_machdep_arg_l(arglist[i], + "phys_offset", + &machdep->machspec->phys_offset)) { + error(NOTE, + "setting phys_offset to: 0x%lx\n\n", + machdep->machspec->phys_offset); + + machdep->flags |= PHYS_OFFSET; + continue; + } else if (arm64_parse_machdep_arg_l(arglist[i], + "kimage_voffset", + &machdep->machspec->kimage_voffset)) { + error(NOTE, + "setting kimage_voffset to: 0x%lx\n\n", + machdep->machspec->kimage_voffset); - machdep->flags |= PHYS_OFFSET; - continue; - } + continue; } error(WARNING, "ignoring --machdep option: %s\n", @@ -631,6 +718,19 @@ arm64_calc_phys_offset(void) if (machdep->flags & PHYS_OFFSET) /* --machdep override */ return; + if (machdep->flags & NEW_VMEMMAP) { + struct syment *sp; + ulong value; + + sp = kernel_symbol_search("memstart_addr"); + if (sp && readmem(sp->value, KVADDR, (char *)&value, + sizeof(value), "memstart_addr", + QUIET|RETURN_ON_ERROR)) { + ms->phys_offset = value; + return; + } + } + /* * Next determine suitable value for phys_offset. User can override this * by passing valid '--machdep phys_offset=<addr>' option. @@ -2377,6 +2477,11 @@ arm64_IS_VMALLOC_ADDR(ulong vaddr) { struct machine_specific *ms = machdep->machspec; + if ((machdep->flags & NEW_VMEMMAP) && + (vaddr >= machdep->machspec->kimage_text) && + (vaddr <= machdep->machspec->kimage_end)) + return FALSE; + return ((vaddr >= ms->vmalloc_start_addr && vaddr <= ms->vmalloc_end) || ((machdep->flags & VMEMMAP) && (vaddr >= ms->vmemmap_vaddr && vaddr <= ms->vmemmap_end)) || @@ -2407,7 +2512,10 @@ arm64_calc_VA_BITS(void) for (bitval = highest_bit_long(value); bitval; bitval--) { if ((value & (1UL << bitval)) == 0) { - machdep->machspec->VA_BITS = bitval + 2; + if (machdep->flags & NEW_VMEMMAP) + machdep->machspec->VA_BITS = bitval + 1; + else + machdep->machspec->VA_BITS = bitval + 2; break; } } @@ -2459,10 +2567,22 @@ arm64_calc_virtual_memory_ranges(void) break; } - vmemmap_size = ALIGN((1UL << (ms->VA_BITS - machdep->pageshift)) * SIZE(page), PUD_SIZE); + if (machdep->flags & NEW_VMEMMAP) +#define STRUCT_PAGE_MAX_SHIFT 6 + vmemmap_size = 1UL << (ms->VA_BITS - machdep->pageshift - 1 + + STRUCT_PAGE_MAX_SHIFT); + else + vmemmap_size = ALIGN((1UL << (ms->VA_BITS - machdep->pageshift)) * SIZE(page), PUD_SIZE); + vmalloc_end = (ms->page_offset - PUD_SIZE - vmemmap_size - SZ_64K); - vmemmap_start = vmalloc_end + SZ_64K; - vmemmap_end = vmemmap_start + vmemmap_size; + + if (machdep->flags & NEW_VMEMMAP) { + vmemmap_start = ms->page_offset - vmemmap_size; + vmemmap_end = ms->page_offset; + } else { + vmemmap_start = vmalloc_end + SZ_64K; + vmemmap_end = vmemmap_start + vmemmap_size; + } ms->vmalloc_end = vmalloc_end - 1; ms->vmemmap_vaddr = vmemmap_start; diff --git a/defs.h b/defs.h index 7af320a..406a865 100644 --- a/defs.h +++ b/defs.h @@ -2846,8 +2846,8 @@ typedef u64 pte_t; #define PTOV(X) \ ((unsigned long)(X)-(machdep->machspec->phys_offset)+(machdep->machspec->page_offset)) -#define VTOP(X) \ - ((unsigned long)(X)-(machdep->machspec->page_offset)+(machdep->machspec->phys_offset)) + +#define VTOP(X) arm64_VTOP((ulong)(X)) #define USERSPACE_TOP (machdep->machspec->userspace_top) #define PAGE_OFFSET (machdep->machspec->page_offset) @@ -2940,18 +2940,23 @@ typedef signed int s32; #define VM_L3_4K (0x10) #define KDUMP_ENABLED (0x20) #define IRQ_STACKS (0x40) +#define NEW_VMEMMAP (0x80) /* * sources: Documentation/arm64/memory.txt * arch/arm64/include/asm/memory.h * arch/arm64/include/asm/pgtable.h */ - -#define ARM64_PAGE_OFFSET ((0xffffffffffffffffUL) << (machdep->machspec->VA_BITS - 1)) +#define ARM64_VA_START ((0xffffffffffffffffUL) \ + << machdep->machspec->VA_BITS) +#define ARM64_PAGE_OFFSET ((0xffffffffffffffffUL) \ + << (machdep->machspec->VA_BITS - 1)) #define ARM64_USERSPACE_TOP ((1UL) << machdep->machspec->VA_BITS) -#define ARM64_MODULES_VADDR (ARM64_PAGE_OFFSET - MEGABYTES(64)) -#define ARM64_MODULES_END (ARM64_PAGE_OFFSET - 1) -#define ARM64_VMALLOC_START ((0xffffffffffffffffUL) << machdep->machspec->VA_BITS) + +/* only used for v4.6 or later */ +#define ARM64_MODULES_VSIZE MEGABYTES(128) +#define ARM64_KASAN_SHADOW_SIZE (1UL << (machdep->machspec->VA_BITS - 3)) + /* * The following 3 definitions are the original values, but are obsolete * for 3.17 and later kernels because they are now build-time calculations. @@ -3030,6 +3035,10 @@ struct machine_specific { ulong kernel_flags; ulong irq_stack_size; ulong *irq_stacks; + /* only needed for v4.6 or later kernel */ + ulong kimage_voffset; + ulong kimage_text; + ulong kimage_end; }; struct arm64_stackframe { @@ -5387,6 +5396,7 @@ void unwind_backtrace(struct bt_info *); #ifdef ARM64 void arm64_init(int); void arm64_dump_machdep_table(ulong); +ulong arm64_VTOP(ulong); int arm64_IS_VMALLOC_ADDR(ulong); ulong arm64_swp_type(ulong); ulong arm64_swp_offset(ulong); diff --git a/main.c b/main.c index 05787f0..4065e9a 100644 --- a/main.c +++ b/main.c @@ -227,9 +227,10 @@ main(int argc, char **argv) optarg); } } else if (STREQ(long_options[option_index].name, "kaslr")) { - if (!machine_type("X86_64")) - error(INFO, "--kaslr only valid " - "with X86_64 machine type.\n"); + if (!machine_type("X86_64") && + !machine_type("ARM64")) + error(INFO, "--kaslr not valid " + "with this machine type.\n"); else if (STREQ(optarg, "auto")) kt->flags2 |= (RELOC_AUTO|KASLR); else { diff --git a/symbols.c b/symbols.c index a8d3563..b0a6461 100644 --- a/symbols.c +++ b/symbols.c @@ -593,7 +593,8 @@ kaslr_init(void) { char *string; - if (!machine_type("X86_64") || (kt->flags & RELOC_SET)) + if ((!machine_type("X86_64") && !machine_type("ARM64")) || + (kt->flags & RELOC_SET)) return; /* @@ -712,7 +713,7 @@ store_symbols(bfd *abfd, int dynamic, void *minisyms, long symcount, if (machine_type("X86")) { if (!(kt->flags & RELOC_SET)) kt->flags |= RELOC_FORCE; - } else if (machine_type("X86_64")) { + } else if (machine_type("X86_64") || machine_type("ARM64")) { if ((kt->flags2 & RELOC_AUTO) && !(kt->flags & RELOC_SET)) derive_kaslr_offset(abfd, dynamic, from, fromend, size, store); @@ -783,7 +784,8 @@ store_sysmap_symbols(void) error(FATAL, "symbol table namespace malloc: %s\n", strerror(errno)); - if (!machine_type("X86") && !machine_type("X86_64")) + if (!machine_type("X86") && !machine_type("X86_64") && + !machine_type("ARM64")) kt->flags &= ~RELOC_SET; first = 0; @@ -833,7 +835,7 @@ store_sysmap_symbols(void) } /* - * Handle x86 kernels configured such that the vmlinux symbols + * Handle x86/arm64 kernels configured such that the vmlinux symbols * are not as loaded into the kernel (not unity-mapped). */ static ulong @@ -4681,7 +4683,7 @@ value_search(ulong value, ulong *offset) if ((sp = machdep->value_to_symbol(value, offset))) return sp; - if (IS_VMALLOC_ADDR(value)) + if (IS_VMALLOC_ADDR(value)) goto check_modules; if ((sp = symval_hash_search(value)) == NULL) -- 2.8.1

----- Original Message ----- Actually it does work on a live system if CONFIG_RANDOMIZE_BASE is not configured. And it also works on live pre-NEW_VMEMMAP kernels now that the VA_BITS calculation has been fixed. The mixture of NEW_VMEMMAP and the old/new unity-mapped translation is confusing. For the sake of simplicity, can you please make it look something like: if (machdep->flags & NEW_VMEMMAP) { /* handle both mapped kernel and unity-mapped addresses here */ ... } else { /* the old VTOP macro */ ... } I don't care if there's duplication of effort for the unity-mapped regions. I just want it to make it more obvious what's going on. s/CONFIG_RANDOMIZE_RAM/CONFIG_RANDOMIZE_BASE/ Certainly not redundant on a live system without CONFIG_RANDOMIZE_BASE. What's the FIXME here? We'll continue to beat a dead horse below in the arm64_calc_phys_offset() patch... As we've discussed before, I cannot accept the chicken-and-egg snippet above. If machdep->machspec->kimage_voffset has not been determined, then the arm64_VTOP() call made by readmem() will utilize machdep->machspec->phys_offset -- which is what you're trying to initialize here. On my live system that has a phys_offset of 0x40000000000, the readmem() will fail quietly, but that's not a acceptable usage of the RETURN_ON_ERROR failure mode, because "memstart_addr" is a legitimate virtual address that should never fail. Also, because the actual kernel phys_offset can be negative, it would seem to be entirely within the realm of possibility that the readmem() could mistakenly return successfully, but have read the wrong location. So what it boils down to is that readmem() should NEVER be called until ALL of the pieces required by arm64_VTOP() have all been properly initialized, however that might be accomplished. Not to mention that calling it this early sets a dangerous precedent. And in the case of kdump's ELF vmcore and compressed vmcore formats, there is an existing API between kdump and the crash utility to pass back the phys_base. In the kexec-tool's makedumpfile.c file, there is the get_phys_base_arm64() function that currently calculates the offset by using the PT_LOAD segments, and presumably will have to be modified to use new VMCOREINFO data. But regardless of how it's done, the architecture-neutral write_kdump_header() laster copies that offset value into the kdump_sub_header.phys_base field for the crash utility to access. Trying to do a readmem() this early in time is essentially breaking that API. Nice -- this was staring us in the face all along, where in the old kernel, the symbol values were in unity-mapped space. This is looking pretty good! Except for arm64_calc_phys_offset()... ;-) Thanks, Dave

----- Original Message ----- I understand, but if you're going to add a comment, it should clarify rather than mystify... ;-) You're right, machdep->identity_map_base is (currently) only used in architecture-specific files, although arm64.c does not use it. But what you have done above is correct. Again, the readmem() is not necessary. I don't think so -- the point is to avoid making a readmem() call this early. Hold on, clarification below... Right, the __PHYS_OFFSET value seems to be the kernel entry point address, but that is not used. Crash needs the PHYS_OFFSET value to mimic the kernel's arm64 __virt_to_phys() function. Sorry about my reference to "kexec-tool's makedumpfile.c file", as I was talking about the Red Hat kexec-tools package, which also contains the makedumpfile facility. Makedumpfile is upstream in a couple places, where the most recently released version (1.5.9) is here: https://sourceforge.net/projects/makedumpfile/files/makedumpfile/ Or the development repository is here: git://git.code.sf.net/p/makedumpfile/code Regardless of which location, there are the generic get_phys_base() macros here in "makedumpfile.h" for those architectures that need it: makedumpfile.h 814 #define get_phys_base() get_phys_base_arm64() makedumpfile.h 826 #define get_phys_base() get_phys_base_arm() makedumpfile.h 837 #define get_phys_base() stub_true() makedumpfile.h 850 #define get_phys_base() get_phys_base_x86_64() makedumpfile.h 861 #define get_phys_base() stub_true() makedumpfile.h 871 #define get_phys_base() stub_true() makedumpfile.h 882 #define get_phys_base() stub_true() makedumpfile.h 894 #define get_phys_base() get_phys_base_ia64() And where the arm64-specific function is in "arch/arm64.c": int get_phys_base_arm64(void) { unsigned long phys_base = ULONG_MAX; unsigned long long phys_start; int i; /* * We resolve phys_base from PT_LOAD segments. LMA contains physical * address of the segment, and we use the lowest start as * phys_base. */ for (i = 0; get_pt_load(i, &phys_start, NULL, NULL, NULL); i++) { if (phys_start < phys_base) phys_base = phys_start; } if (phys_base == ULONG_MAX) { ERRMSG("Can't determine phys_base\n"); return FALSE; } info->phys_base = phys_base; DEBUG_MSG("phys_base : %lx\n", phys_base); return TRUE; } Note that it currently looks for the lowest physical address that is referenced in any of the PT_LOAD segments of /proc/vmcore. As you have discussed for Linux 4.6, perhaps it will be necessary that the value of PHYS_OFFSET ("memstart_addr") will have to be passed in a VMCOREINFO item. It's not clear to me why PT_LOAD p_paddr values will no longer be usable, but that's up to the makedumpfile/kdump maintainers. And certainly a convenient VMCOREINFO item would be ideal/preferable. Anyway, later on, the info->phys_base value gets stored in the compressed kdump header in the write_kdump_header() function in "makedumpfile.c": int write_kdump_header(void) { int ret = FALSE; size_t size; off_t offset_note, offset_vmcoreinfo; unsigned long size_note, size_vmcoreinfo; struct disk_dump_header *dh = info->dump_header; struct kdump_sub_header kh; char *buf = NULL; ... [ cut ] ... /* * Write sub header */ size = sizeof(struct kdump_sub_header); memset(&kh, 0, size); /* 64bit max_mapnr_64 */ kh.max_mapnr_64 = info->max_mapnr; kh.phys_base = info->phys_base; kh.dump_level = info->dump_level; ... And then in the crash utility source code, it simply gets accessed like so: int diskdump_phys_base(unsigned long *phys_base) { if (KDUMP_CMPRS_VALID()) { *phys_base = dd->sub_header_kdump->phys_base; return TRUE; } return FALSE; } Now, for ELF vmcores, the crash utility calls arm64_kdump_phys_base() which calls arm_kdump_phys_base(), which simply mimics what the makedumpfile.c's get_phys_base_arm64() does. And that function may need to be changed for Linux 4.6 in order to access the new VMCOREINFO variable. Clear as mud? Dave

----- Original Message ----- Sure, that's better. Right -- there's nothing to fix! The VMCOREINFO is primarily there for the user-space kdump and makedumpfile facilities. Crash does check it occasionally, but can't depend upon it, because there are too many other dumpfile formats. I'm sure I don't understand. Calling READMEM() as opposed to readmem() would require the virtual-to-physical address translation to be done on the "memstart_addr" symbol. Anyway, READMEM should be hidden and constrained to readmem() itself. (It is used in one other odd-ball place prior to pc->readmem being initialized and a System.map file being used as the correct source of kernel symbol values.) Right, there are going to be kdump/makedumpfile requirements, one of them being the capability of setting the phys_base value in the kdump_sub_header. It won't have to -- it has always used diskdump_phys_base(). Now, for kdump ELF vmcores, yes, it could use pc->read_vmcoreinfo(). Makedumpfile may require VA_BITS, but it's pretty straight forward in crash because we have the symbol values from the vmlinux file. That being the case, if it's available in VMCOREINFO, it could be used as an alternative for compressed kdumps or kdump ELF vmcores. Right, although it's going to be kind of play-as-we-go. The crash utility is going to require kdump-ELF and makedumpfile to offer the the things that it needs, but kdump-ELF/makedumpfile may have its own requirements to generate the things that the crash utility needs. As far as I can tell, at a minimum, VA_BITS, kimage_voffset and PHYS_BASE would be required. Thanks, Dave

This patch looks good -- if it wasn't layered on top of the KASLR patch, I would check it into github. Thanks, Dave ----- Original Message -----