Re: [PATCH v11 11/15] arm64: kexec_file: add crash dump support
Hi James,
On Wed, Jul 18, 2018 at 05:50:22PM +0100, James Morse wrote:
> Hi Akashi,
>
> On 11/07/18 08:41, AKASHI Takahiro wrote:
> > Enabling crash dump (kdump) includes
> > * prepare contents of ELF header of a core dump file, /proc/vmcore,
> > using crash_prepare_elf64_headers(), and
> > * add two device tree properties, "linux,usable-memory-range" and
> > "linux,elfcorehdr", which represent respectively a memory range
> > to be used by crash dump kernel and the header's location
>
> > diff --git a/arch/arm64/include/asm/kexec.h b/arch/arm64/include/asm/kexec.h
> > index 69333694e3e2..eeb5766928b0 100644
> > --- a/arch/arm64/include/asm/kexec.h
> > +++ b/arch/arm64/include/asm/kexec.h
> > @@ -99,6 +99,10 @@ static inline void crash_post_resume(void) {}
> > struct kimage_arch {
> > phys_addr_t dtb_mem;
> > void *dtb_buf;
> > + /* Core ELF header buffer */
>
> > + void *elf_headers;
>
> Shouldn't this be a phys_addr_t if it comes from kbuf.mem?
Do you mean elf_load_addr? You're right.
But kexec_buf defined mem as unsigned long and so I'd rather change
dtb_mem to unsigned long instead of elf_load_addr, which will also be
renamed to elf_headers_mem for clarification.
> (dtb_mem is, and they type tells us which way round the runtime/kexec-time
> pointers are)
>
>
> > + unsigned long elf_headers_sz;
> > + unsigned long elf_load_addr;
> > };
> >
> > /**
>
>
> > diff --git a/arch/arm64/kernel/machine_kexec_file.c
> > b/arch/arm64/kernel/machine_kexec_file.c
> > index a0b44fe18b95..261564df7210 100644
> > --- a/arch/arm64/kernel/machine_kexec_file.c
> > +++ b/arch/arm64/kernel/machine_kexec_file.c
> > @@ -132,6 +173,45 @@ static int setup_dtb(struct kimage *image,
> > return ret;
> > }
> >
> > +static int prepare_elf_headers(void **addr, unsigned long *sz)
> > +{
> > + struct crash_mem *cmem;
> > + unsigned int nr_ranges;
> > + int ret;
> > + u64 i;
> > + phys_addr_t start, end;
>
> > + nr_ranges = 1; /* for exclusion of crashkernel region */
> > + for_each_mem_range(i, , NULL, NUMA_NO_NODE, 0,
> > + , , NULL)
>
> Nit: flags = MEMBLOCK_NONE? Just to make it obvious this is how MEMBLOCK_NOMAP
> regions are weeded out.
OK.
> This is going to get interesting if we ever support hotpluggable memory... but
> it works for now and implicitly removes the nomap regions.
>
>
> > + nr_ranges++;
>
> > +
> > + cmem = kmalloc(sizeof(struct crash_mem) +
> > + sizeof(struct crash_mem_range) * nr_ranges, GFP_KERNEL);
> > + if (!cmem)
> > + return -ENOMEM;
> > +
> > + cmem->max_nr_ranges = nr_ranges;
> > + cmem->nr_ranges = 0;
> > + for_each_mem_range(i, , NULL, NUMA_NO_NODE, 0,
> > + , , NULL) {
> > + cmem->ranges[cmem->nr_ranges].start = start;
> > + cmem->ranges[cmem->nr_ranges].end = end - 1;
> > + cmem->nr_ranges++;
> > + }
> > +
> > + /* Exclude crashkernel region */
> > + ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end);
>
>
> > + if (ret)
> > + goto out;
> > +
> > + ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
> > +
> > +out:
>
> Nit: You could save the goto if you wrote this as:
> | if (!ret)
> | ret = crash_prepare_elf64_headers(cmem, true, addr, sz);
OK.
> > + kfree(cmem);
> > + return ret;
> > +}
> > +
> > int load_other_segments(struct kimage *image,
> > unsigned long kernel_load_addr,
> > unsigned long kernel_size,
> > @@ -139,11 +219,43 @@ int load_other_segments(struct kimage *image,
> > char *cmdline, unsigned long cmdline_len)
> > {
> > struct kexec_buf kbuf;
> > + void *hdrs_addr;
> > + unsigned long hdrs_sz;
> > unsigned long initrd_load_addr = 0;
> > char *dtb = NULL;
> > unsigned long dtb_len = 0;
> > int ret = 0;
> >
> > + /* load elf core header */
> > + if (image->type == KEXEC_TYPE_CRASH) {
> > + ret = prepare_elf_headers(_addr, _sz);
> > + if (ret) {
> > + pr_err("Preparing elf core header failed\n");
> > + goto out_err;
> > + }
> > +
> > + kbuf.image = image;
> > + kbuf.buffer = hdrs_addr;
> > + kbuf.bufsz = hdrs_sz;
> > + kbuf.memsz = hdrs_sz;
>
> > + kbuf.buf_align = PAGE_SIZE;
>
> Whose PAGE_SIZE?
>
> Won't this break if the kdump kernel is 64K pages, but the first kernel uses
> 4K?
> Should we change this to the largest supported PAGE_SIZE: SZ_64K?
Ah, yes.
> > + kbuf.buf_min = crashk_res.start;
> > + kbuf.buf_max = crashk_res.end + 1;
> > + kbuf.top_down = true;
> > +
> > + ret = kexec_add_buffer();
> > + if (ret) {
> > + vfree(hdrs_addr);
> > + goto out_err;
> > + }
> > +
[PATCH v4 3/5] efi/arm: preserve early mapping of UEFI memory map longer for BGRT
From: Ard Biesheuvel
The BGRT code validates the contents of the table against the UEFI
memory map, and so it expects it to be mapped when the code runs.
On ARM, this is currently not the case, since we tear down the early
mapping after efi_init() completes, and only create the permanent
mapping in arm_enable_runtime_services(), which executes as an early
initcall, but still leaves a window where the UEFI memory map is not
mapped.
So move the call to efi_memmap_unmap() from efi_init() to
arm_enable_runtime_services().
Signed-off-by: Ard Biesheuvel
---
drivers/firmware/efi/arm-init.c| 1 -
drivers/firmware/efi/arm-runtime.c | 2 ++
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
index b5214c143fee..388a929baf95 100644
--- a/drivers/firmware/efi/arm-init.c
+++ b/drivers/firmware/efi/arm-init.c
@@ -259,7 +259,6 @@ void __init efi_init(void)
reserve_regions();
efi_esrt_init();
- efi_memmap_unmap();
memblock_reserve(params.mmap & PAGE_MASK,
PAGE_ALIGN(params.mmap_size +
diff --git a/drivers/firmware/efi/arm-runtime.c
b/drivers/firmware/efi/arm-runtime.c
index 5889cbea60b8..59a8c0ec94d5 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -115,6 +115,8 @@ static int __init arm_enable_runtime_services(void)
return 0;
}
+ efi_memmap_unmap();
+
if (efi_runtime_disabled()) {
pr_info("EFI runtime services will be disabled.\n");
return 0;
--
2.18.0
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH v4 5/5] arm64: acpi: fix alignment fault in accessing ACPI
This is a fix against the issue that crash dump kernel may hang up
during booting, which can happen on any ACPI-based system with "ACPI
Reclaim Memory."
(kernel messages after panic kicked off kdump)
(snip...)
Bye!
(snip...)
ACPI: Core revision 20170728
pud=2e7d0003, *pmd=2e7c0003, *pte=00e839710707
Internal error: Oops: 9621 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.0-rc6 #1
task: 08d05180 task.stack: 08cc
PC is at acpi_ns_lookup+0x25c/0x3c0
LR is at acpi_ds_load1_begin_op+0xa4/0x294
(snip...)
Process swapper/0 (pid: 0, stack limit = 0x08cc)
Call trace:
(snip...)
[] acpi_ns_lookup+0x25c/0x3c0
[] acpi_ds_load1_begin_op+0xa4/0x294
[] acpi_ps_build_named_op+0xc4/0x198
[] acpi_ps_create_op+0x14c/0x270
[] acpi_ps_parse_loop+0x188/0x5c8
[] acpi_ps_parse_aml+0xb0/0x2b8
[] acpi_ns_one_complete_parse+0x144/0x184
[] acpi_ns_parse_table+0x48/0x68
[] acpi_ns_load_table+0x4c/0xdc
[] acpi_tb_load_namespace+0xe4/0x264
[] acpi_load_tables+0x48/0xc0
[] acpi_early_init+0x9c/0xd0
[] start_kernel+0x3b4/0x43c
Code: b9008fb9 2a000318 36380054 32190318 (b94002c0)
---[ end trace c46ed37f9651c58e ]---
Kernel panic - not syncing: Fatal exception
Rebooting in 10 seconds..
(diagnosis)
* This fault is a data abort, alignment fault (ESR=0x9621)
during reading out ACPI table.
* Initial ACPI tables are normally stored in system ram and marked as
"ACPI Reclaim memory" by the firmware.
* After the commit f56ab9a5b73c ("efi/arm: Don't mark ACPI reclaim
memory as MEMBLOCK_NOMAP"), those regions are differently handled
as they are "memblock-reserved", without NOMAP bit.
* So they are now excluded from device tree's "usable-memory-range"
which kexec-tools determines based on a current view of /proc/iomem.
* When crash dump kernel boots up, it tries to accesses ACPI tables by
mapping them with ioremap(), not ioremap_cache(), in acpi_os_ioremap()
since they are no longer part of mapped system ram.
* Given that ACPI accessor/helper functions are compiled in without
unaligned access support (ACPI_MISALIGNMENT_NOT_SUPPORTED),
any unaligned access to ACPI tables can cause a fatal panic.
With this patch, acpi_os_ioremap() always honors memory attribute
information provided by the firmware (EFI) and retaining cacheability
allows the kernel safe access to ACPI tables.
Signed-off-by: AKASHI Takahiro
Reviewed-by: James Morse
Reviewed-by: Ard Biesheuvel
Reported-by and Tested-by: Bhupesh Sharma
---
arch/arm64/include/asm/acpi.h | 23 ---
arch/arm64/kernel/acpi.c | 11 +++
2 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 0db62a4cbce2..68bc18cb2b85 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -12,10 +12,12 @@
#ifndef _ASM_ACPI_H
#define _ASM_ACPI_H
+#include
#include
#include
#include
+#include
#include
#include
@@ -29,18 +31,22 @@
/* Basic configuration for ACPI */
#ifdef CONFIG_ACPI
+pgprot_t __acpi_get_mem_attribute(phys_addr_t addr);
+
/* ACPI table mapping after acpi_permanent_mmap is set */
static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
{
+ /* For normal memory we already have a cacheable mapping. */
+ if (memblock_is_map_memory(phys))
+ return (void __iomem *)__phys_to_virt(phys);
+
/*
-* EFI's reserve_regions() call adds memory with the WB attribute
-* to memblock via early_init_dt_add_memory_arch().
+* We should still honor the memory's attribute here because
+* crash dump kernel possibly excludes some ACPI (reclaim)
+* regions from memblock list.
*/
- if (!memblock_is_memory(phys))
- return ioremap(phys, size);
-
- return ioremap_cache(phys, size);
+ return __ioremap(phys, size, __acpi_get_mem_attribute(phys));
}
#define acpi_os_ioremap acpi_os_ioremap
@@ -129,7 +135,10 @@ static inline const char *acpi_get_enable_method(int cpu)
* for compatibility.
*/
#define acpi_disable_cmcff 1
-pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
+static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+{
+ return __acpi_get_mem_attribute(addr);
+}
#endif /* CONFIG_ACPI_APEI */
#ifdef CONFIG_ACPI_NUMA
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 7b09487ff8fb..ed46dc188b22 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -29,13
[PATCH v4 4/5] efi/arm: map UEFI memory map even w/o runtime services enabled
Under the current implementation, UEFI memory map will be mapped and made
available in virtual mappings only if runtime services are enabled.
But in a later patch, we want to use UEFI memory map in acpi_os_ioremap()
to create mappings of ACPI tables using memory attributes described in
UEFI memory map.
See the following commit:
arm64: acpi: fix alignment fault in accessing ACPI tables
So, as a first step, arm_enter_runtime_services() is modified, alongside
Ard's patch[1], so that UEFI memory map will not be freed even if
efi=noruntime.
[1] https://marc.info/?l=linux-efi=152930773507524=2
Signed-off-by: AKASHI Takahiro
Reviewed-by: Ard Biesheuvel
---
drivers/firmware/efi/arm-runtime.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/firmware/efi/arm-runtime.c
b/drivers/firmware/efi/arm-runtime.c
index 59a8c0ec94d5..a00934d263c5 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -117,6 +117,13 @@ static int __init arm_enable_runtime_services(void)
efi_memmap_unmap();
+ mapsize = efi.memmap.desc_size * efi.memmap.nr_map;
+
+ if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) {
+ pr_err("Failed to remap EFI memory map\n");
+ return 0;
+ }
+
if (efi_runtime_disabled()) {
pr_info("EFI runtime services will be disabled.\n");
return 0;
@@ -129,13 +136,6 @@ static int __init arm_enable_runtime_services(void)
pr_info("Remapping and enabling EFI services.\n");
- mapsize = efi.memmap.desc_size * efi.memmap.nr_map;
-
- if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) {
- pr_err("Failed to remap EFI memory map\n");
- return -ENOMEM;
- }
-
if (!efi_virtmap_init()) {
pr_err("UEFI virtual mapping missing or invalid -- runtime
services will not be available\n");
return -ENOMEM;
--
2.18.0
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH v4 2/5] drivers: acpi: add dependency of EFI for arm64
As Ard suggested, CONFIG_ACPI && !CONFIG_EFI doesn't make sense on arm64, while CONFIG_ACPI and CONFIG_CPU_BIG_ENDIAN doesn't make sense either. As CONFIG_EFI already has a dependency of !CONFIG_CPU_BIG_ENDIAN, it is good enough to add a dependency of CONFIG_EFI to avoid any useless combination of configuration. This bug, reported by Will, will be revealed when my patch series, "arm64: kexec,kdump: fix boot failures on acpi-only system," is applied and the kernel is built under allmodconfig. Signed-off-by: AKASHI Takahiro Suggested-by: Ard Biesheuvel --- drivers/acpi/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index b533eeb6139d..15ab1daaa808 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -6,7 +6,7 @@ menuconfig ACPI bool "ACPI (Advanced Configuration and Power Interface) Support" depends on !IA64_HP_SIM - depends on IA64 || X86 || ARM64 + depends on IA64 || X86 || (ARM64 && EFI) depends on PCI select PNP default y if (IA64 || X86) -- 2.18.0 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[PATCH v4 1/5] arm64: export memblock_reserve()d regions via /proc/iomem
From: James Morse
There has been some confusion around what is necessary to prevent kexec
overwriting important memory regions. memblock: reserve, or nomap?
Only memblock nomap regions are reported via /proc/iomem, kexec's
user-space doesn't know about memblock_reserve()d regions.
Until commit f56ab9a5b73ca ("efi/arm: Don't mark ACPI reclaim memory
as MEMBLOCK_NOMAP") the ACPI tables were nomap, now they are reserved
and thus possible for kexec to overwrite with the new kernel or initrd.
But this was always broken, as the UEFI memory map is also reserved
and not marked as nomap.
Exporting both nomap and reserved memblock types is a nuisance as
they live in different memblock structures which we can't walk at
the same time.
Take a second walk over memblock.reserved and add new 'reserved'
subnodes for the memblock_reserved() regions that aren't already
described by the existing code. (e.g. Kernel Code)
We use reserve_region_with_split() to find the gaps in existing named
regions. This handles the gap between 'kernel code' and 'kernel data'
which is memblock_reserve()d, but already partially described by
request_standard_resources(). e.g.:
| 8000-dfff : System RAM
| 8008-80ff : Kernel code
| 8100-8158 : reserved
| 8159-8237efff : Kernel data
| a000-dfff : Crash kernel
| e00f-f949 : System RAM
reserve_region_with_split needs kzalloc() which isn't available when
request_standard_resources() is called, use an initcall.
Reported-by: Bhupesh Sharma
Reported-by: Tyler Baicar
Suggested-by: Akashi Takahiro
Signed-off-by: James Morse
Fixes: d28f6df1305a ("arm64/kexec: Add core kexec support")
Reviewed-by: Ard Biesheuvel
CC: Mark Rutland
---
arch/arm64/kernel/setup.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 30ad2f085d1f..5b4fac434c84 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -241,6 +241,44 @@ static void __init request_standard_resources(void)
}
}
+static int __init reserve_memblock_reserved_regions(void)
+{
+ phys_addr_t start, end, roundup_end = 0;
+ struct resource *mem, *res;
+ u64 i;
+
+ for_each_reserved_mem_region(i, , ) {
+ if (end <= roundup_end)
+ continue; /* done already */
+
+ start = __pfn_to_phys(PFN_DOWN(start));
+ end = __pfn_to_phys(PFN_UP(end)) - 1;
+ roundup_end = end;
+
+ res = kzalloc(sizeof(*res), GFP_ATOMIC);
+ if (WARN_ON(!res))
+ return -ENOMEM;
+ res->start = start;
+ res->end = end;
+ res->name = "reserved";
+ res->flags = IORESOURCE_MEM;
+
+ mem = request_resource_conflict(_resource, res);
+ /*
+* We expected memblock_reserve() regions to conflict with
+* memory created by request_standard_resources().
+*/
+ if (WARN_ON_ONCE(!mem))
+ continue;
+ kfree(res);
+
+ reserve_region_with_split(mem, start, end, "reserved");
+ }
+
+ return 0;
+}
+arch_initcall(reserve_memblock_reserved_regions);
+
u64 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = INVALID_HWID };
void __init setup_arch(char **cmdline_p)
--
2.18.0
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH v4 0/5] arm64: kexec, kdump: fix boot failures on acpi-only system
This patch series is a set of bug fixes to address kexec/kdump failures which are sometimes observed on ACPI-only system and reported in LAK-ML before. In short, the phenomena are: 1. kexec'ed kernel can fail to boot because some ACPI table is corrupted by a new kernel (or other data) being loaded into System RAM. Currently kexec may possibly allocate space ignoring such "reserved" regions. We will see no messages after "Bye!" 2. crash dump (kdump) kernel can fail to boot and get into panic due to an alignment fault when accessing ACPI tables. This can happen because those tables are not always properly aligned while they are mapped non-cacheable (ioremap'ed) as they are not recognized as part of System RAM under the current implementation. After discussing several possibilities to address those issues, the agreed approach, in my understanding, is * to add resource entries for every "reserved", i.e. memblock_reserve(), regions to /proc/iomem. (NOMAP regions, also marked as "reserved," remains at top-level for backward compatibility. User-space can tell the difference between reserved-system-ram and reserved-address-space.) * For case (1), user space (kexec-tools) should rule out such regions in searching for free space for loaded data. * For case (2), the kernel should access ACPI tables by mapping them with appropriate memory attributes described in UEFI memory map. (This means that it doesn't require any changes in /proc/iomem, and hence user space.) Please find past discussions about /proc/iomem in [1]. --- more words from James --- Our attempts to fix this just in the kernel reached a dead end, because Kdump needs to include reserved-system-ram, whereas kexec has to avoid it. User-space needs to be able to tell reserved-system-ram and reserved-address-space apart. Hence we need to expose that information, and pick it up in user-space. Patched-kernel and unpatch-user-space will work the same way it does today, as the additional reserved regions are ignored by user-space. Unpatched-kernel and patched-user-space will also work the same way it does today as the additional reserved regions are missing. --->8--- Patch#1 addresses kexec case, for which you are also required to update user space. See necessary patches in [2]. If you want to review Patch#1, please also take a look at and review [2]. Patch#2, #3, #4 and #5 address the kdump case above. Changes in v4 (2018, July 23, 2018) * correct configuration dependency for ACPI (patch#2) Changes in v3.1 (2018, July 10, 2018) * add Ard's patch[4] to this patch set Changes in v3 (2018, July 9, 2018) * drop the v2's patch#3, preferring [4] Changes in v2 (2018, June 19, 2018) * re-organise v1's patch#2 and #3 into v2's #2, #3 and #4 not to break bisect [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/565980.html [2] https://git.linaro.org/people/takahiro.akashi/kexec-tools.git arm64/resv_mem [3] http://lists.infradead.org/pipermail/linux-arm-kernel/2018-April/573655.html [4] https://marc.info/?l=linux-efi=152930773507524=2 AKASHI Takahiro (3): drivers: acpi: add dependency of EFI for arm64 efi/arm: map UEFI memory map even w/o runtime services enabled arm64: acpi: fix alignment fault in accessing ACPI Ard Biesheuvel (1): efi/arm: preserve early mapping of UEFI memory map longer for BGRT James Morse (1): arm64: export memblock_reserve()d regions via /proc/iomem arch/arm64/include/asm/acpi.h | 23 -- arch/arm64/kernel/acpi.c | 11 +++-- arch/arm64/kernel/setup.c | 38 ++ drivers/acpi/Kconfig | 2 +- drivers/firmware/efi/arm-init.c| 1 - drivers/firmware/efi/arm-runtime.c | 16 +++-- 6 files changed, 67 insertions(+), 24 deletions(-) -- 2.18.0 ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
mail with .c files in attachment held in moderation
messages from yesterday are still held in moderation for "suspicious header". i suspect this is because i attached c source file. can someone please check? should i send hyperlinks instead? -- cinap ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH 1/2] arm64: Get 'info->page_offset' from PT_LOAD segments to support KASLR boot cases
Hello Kazu,
Many thanks for your review comments.
On Sat, Jul 21, 2018 at 3:18 AM, Kazuhito Hagio wrote:
>
> On 7/19/2018 1:43 AM, Bhupesh Sharma wrote:
>> The existing methodology to obtain 'info->page_offset' from reading
>> _stext symbol (from kallsyms) doesn't work well in KASLR boot cases on
>> arm64 machines as the PAGE_OFFSET (or the virtual address which
>> indicates the start of the linear region) can be randomized as well
>> on basis of the kaslr-seed.
>>
>> Since the value of PAGE_OFFSET inside the kernel is randomized in such
>> cases and there is no existing mechanism of conveying this value from
>> kernel-space to user-space, so we can use the method used by archs like
>> x86_64 to generate the 'info->page_offset' value from the PT_LOAD
>> segments by subtracting the phy_addr from virt_addr of a PT_LOAD
>> segment.
>>
>> This approach works fine both with KASLR and non-KASLR boot cases.
>>
>> I tested this on my qualcomm-amberwing board. Here are some logs from
>> the KASLR boot cases:
>>
>> - Verify that the EFI firmware supports 'kaslr-seed':
>>
>> chosen {
>> kaslr-seed = <0x0 0x0>;
>> <..snip..>
>> };
>>
>> - Verify that '--mem-usage' works well after this fix as well (I used
>> kernel 4.18.0-rc4+ for my checks):
>>
>> The kernel version is not supported.
>> The makedumpfile operation may be incomplete.
>>
>> TYPE PAGES EXCLUDABLE DESCRIPTION
>> --
>> ZERO 4396yes Pages filled
>> with zero
>> NON_PRI_CACHE 27859 yes Cache pages
>> without private flag
>> PRI_CACHE 18490 yes Cache pages with
>> private flag
>> USER 2728yes User process
>> pages
>> FREE 1465848 yes Free pages
>> KERN_DATA 18537 no Dumpable kernel
>> data
>>
>> page size:65536
>> Total pages on system:1537858
>> Total size on system: 100785061888 Byte
>>
>> Signed-off-by: Bhupesh Sharma
>> ---
>> arch/arm64.c | 23 ++-
>> common.h | 1 +
>> makedumpfile.h | 1 +
>> 3 files changed, 20 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64.c b/arch/arm64.c
>> index 2fd3e1874376..9e8c77c76935 100644
>> --- a/arch/arm64.c
>> +++ b/arch/arm64.c
>> @@ -265,6 +265,9 @@ get_xen_info_arm64(void)
>> int
>> get_versiondep_info_arm64(void)
>> {
>> + int i;
>> + unsigned long long phys_start;
>> + unsigned long long virt_start;
>> ulong _stext;
>>
>> _stext = get_stext_symbol();
>> @@ -289,12 +292,22 @@ get_versiondep_info_arm64(void)
>> return FALSE;
>> }
>>
>
>> - info->page_offset = (0xUL) << (va_bits - 1);
>> -
>> - DEBUG_MSG("page_offset=%lx, va_bits=%d\n", info->page_offset,
>> - va_bits);
>
> According to makedumpfile commit 4944f93484 ("x86_64: Calculate page_offset
> in case of re-filtering/sadump/virsh dump"), in case of re-filtering,
> we don't have any PT_LOAD. So, with this patch, we cannot re-filter
> dump file on arm64 system?
>
> If we cannot, is it better to leave the above behind the following
> pt_load section for re-filtering non-KASLR dump?
>
>> + if (get_num_pt_loads()) {
>> + for (i = 0;
>> + get_pt_load(i, _start, NULL, _start, NULL);
>> + i++) {
>> + if (virt_start != NOT_KV_ADDR
>> + && virt_start < __START_KERNEL_map
>> + && phys_start != NOT_PADDR &&
>> phys_start != NOT_PADDR_ARM64) {
>> + info->page_offset = virt_start - phys_start;
>> + DEBUG_MSG("info->page_offset: %lx, VA_BITS:
>> %d\n",
>> + info->page_offset, va_bits);
>> + return TRUE;
>> + }
>> + }
>> + }
>
> I'll adjust some indents for readability.
>
>>
>> - return TRUE;
>> + return FALSE;
>> }
>>
>> /*
>> diff --git a/common.h b/common.h
>> index 6e2f657a79c7..a8181777dbb7 100644
>> --- a/common.h
>> +++ b/common.h
>> @@ -48,6 +48,7 @@
>> #define NOT_MEMMAP_ADDR (0x0)
>> #define NOT_KV_ADDR (0x0)
>> #define NOT_PADDR(ULONGLONG_MAX)
>
>> +#define NOT_PADDR_ARM64 (0x10a8UL)
>
> I think that this should not be in common.h, because it's not for
> arch-specific definitions, so I'll move it to makedumpfile.h.
>
>> #define BADADDR ((ulong)(-1))
>>
>> #endif /* COMMON_H */
>> diff --git a/makedumpfile.h b/makedumpfile.h
>> index 5ff94b8e4ac6..5297279f0f3b 100644
>> --- a/makedumpfile.h
>> +++ b/makedumpfile.h
>> @@ -2020,6 +2020,7 @@ struct domain_list {
>> #define MFNS_PER_FRAME
