[PATCH 0/2] arm64, makedumpfile: A couple of KASLR related fixes

[PATCH 0/2] arm64, makedumpfile: A couple of KASLR related fixes

[Bhupesh Sharma]

This patchset contains a couple of patches which provide important
arm64 fixes for KASLR boot cases:

PATCH 1 -> Addresses the issue with 'info->page_offset' calculation for
           KASLR cases.
PATCH 2 -> Addresses the issue with filtering not able to translate
           symbol address from vmlinux to kernel run time address in
	   case of KASLR boot.

Bhupesh Sharma (2):
  arm64: Get 'info->page_offset' from PT_LOAD segments to support KASLR
    boot cases
  arm64: Add runtime kaslr offset if it exists

 arch/arm64.c   | 64 +++++++++++++++++++++++++++++++++++++++++++++++++++++-----
 common.h       |  1 +
 makedumpfile.h |  4 +++-
 3 files changed, 63 insertions(+), 6 deletions(-)

-- 
2.7.4


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 1/2] arm64: Get 'info->page_offset' from PT_LOAD segments to support KASLR boot cases

[Bhupesh Sharma]

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		4396            	yes		Pages filled
with zero
NON_PRI_CACHE	27859           	yes		Cache pages
without private flag
PRI_CACHE	18490           	yes		Cache pages with
private flag
USER		2728            	yes		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 <bhsharma@redhat.com>
---
 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 = (0xffffffffffffffffUL) << (va_bits - 1);
-
-	DEBUG_MSG("page_offset=%lx, va_bits=%d\n", info->page_offset,
-			va_bits);
+	if (get_num_pt_loads()) {
+		for (i = 0;
+			get_pt_load(i, &phys_start, NULL, &virt_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;
+			}
+		}
+	}
 
-	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	(0x0000000010a80000UL)
 #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		(info->page_size / sizeof(unsigned long))
 
 #ifdef __aarch64__
+#define __START_KERNEL_map		(0xffffffff80000000UL)
 unsigned long long kvtop_xen_arm64(unsigned long kvaddr);
 #define kvtop_xen(X)	kvtop_xen_arm64(X)
 #endif /* aarch64 */
-- 
2.7.4


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

[PATCH 2/2] arm64: Add runtime kaslr offset if it exists

[Bhupesh Sharma]

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:
   # cat > scrub.conf << EOF
   [vmlinux]
   erase jiffies
   erase init_task.utime
   for tsk in init_task.tasks.next within task_struct:tasks
       erase tsk.utime
   endfor
   EOF

  # makedumpfile --split -d 31 -x vmlinux --config scrub.conf vmcore dumpfile_{1,2,3}
  readpage_elf: Attempt to read non-existent page at 0xffffa8a5bf180000.
  readmem: type_addr: 1, addr:ffffa8a5bf180000, size:8
  vaddr_to_paddr_arm64: Can't read pgd
  readmem: Can't convert a virtual address(ffff0000092a542c) to physical
  address.
  readmem: type_addr: 0, addr:ffff0000092a542c, 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 (I checked this with kernel 4.18.0-rc4+):

  # makedumpfile --split -d 31 -x vmlinux --config scrub.conf vmcore dumpfile_{1,2,3}
  The kernel version is not supported.
  The makedumpfile operation may be incomplete.
  Checking for memory holes                         : [100.0 %] \
  Checking for memory holes                         : [100.0 %] |
  Checking foExcluding unnecessary pages                       : [100.0 %]
  \
  Excluding unnecessary pages                       : [100.0 %] \

  The dumpfiles are saved to dumpfile_1, dumpfile_2, and dumpfile_3.

  makedumpfile Completed.

This feature also requires a fix in the kernel as well which has been submitted
upstream (see[0]).

[0] https://patchwork.kernel.org/patch/10533333/

Signed-off-by: Bhupesh Sharma <bhsharma@redhat.com>
---
 arch/arm64.c   | 41 +++++++++++++++++++++++++++++++++++++++++
 makedumpfile.h |  3 ++-
 2 files changed, 43 insertions(+), 1 deletion(-)

diff --git a/arch/arm64.c b/arch/arm64.c
index 9e8c77c76935..9772022605ec 100644
--- a/arch/arm64.c
+++ b/arch/arm64.c
@@ -181,6 +181,47 @@ get_phys_base_arm64(void)
 	return TRUE;
 }
 
+unsigned long
+get_kaslr_offset_arm64(unsigned long vaddr)
+{
+	unsigned int i;
+	char buf[BUFSIZE_FGETS], *endp;
+
+	if (!info->kaslr_offset && info->file_vmcoreinfo) {
+		if (fseek(info->file_vmcoreinfo, 0, SEEK_SET) < 0) {
+			ERRMSG("Can't seek the vmcoreinfo file(%s). %s\n",
+					info->name_vmcoreinfo, strerror(errno));
+			return FALSE;
+		}
+
+		while (fgets(buf, BUFSIZE_FGETS, info->file_vmcoreinfo)) {
+			i = strlen(buf);
+			if (!i)
+				break;
+			if (buf[i - 1] == '\n')
+				buf[i - 1] = '\0';
+			if (strncmp(buf, STR_KERNELOFFSET,
+					strlen(STR_KERNELOFFSET)) == 0) {
+				info->kaslr_offset =
+					strtoul(buf+strlen(STR_KERNELOFFSET),&endp,16);
+				DEBUG_MSG("info->kaslr_offset: %lx\n", info->kaslr_offset);
+			}
+		}
+	}
+
+	if (vaddr >= __START_KERNEL_map &&
+			vaddr < __START_KERNEL_map + info->kaslr_offset) {
+		DEBUG_MSG("info->kaslr_offset: %lx\n", 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;
+	}
+}
+
 ulong
 get_stext_symbol(void)
 {
diff --git a/makedumpfile.h b/makedumpfile.h
index 5297279f0f3b..4daf71ef14b7 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -967,12 +967,13 @@ unsigned long long vaddr_to_paddr_arm64(unsigned long vaddr);
 int get_versiondep_info_arm64(void);
 int get_xen_basic_info_arm64(void);
 int get_xen_info_arm64(void);
+unsigned long get_kaslr_offset_arm64(unsigned long vaddr);
 #define find_vmemmap()		stub_false()
 #define vaddr_to_paddr(X)	vaddr_to_paddr_arm64(X)
 #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)	stub_false()
+#define get_kaslr_offset(X)	get_kaslr_offset_arm64(X)
 #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)
-- 
2.7.4


_______________________________________________
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

[Kazuhito Hagio]

[-- Attachment #1: Type: text/plain, Size: 4639 bytes --]


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		4396            	yes		Pages filled
> with zero
> NON_PRI_CACHE	27859           	yes		Cache pages
> without private flag
> PRI_CACHE	18490           	yes		Cache pages with
> private flag
> USER		2728            	yes		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 <bhsharma@redhat.com>
> ---
>  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 = (0xffffffffffffffffUL) << (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, &phys_start, NULL, &virt_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	(0x0000000010a80000UL)

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		(info->page_size / sizeof(unsigned long))
>  
>  #ifdef __aarch64__
> +#define __START_KERNEL_map		(0xffffffff80000000UL)

This #ifdef here is for the definitions related to Xen extraction.
I'll move it to the same place as the above.

>  unsigned long long kvtop_xen_arm64(unsigned long kvaddr);
>  #define kvtop_xen(X)	kvtop_xen_arm64(X)
>  #endif /* aarch64 */
> 

I attached a patch that was applied my suggestions.
How about it?

Thanks,
Kazu


[-- Attachment #2: arm64-page_offset-01.patch --]
[-- Type: text/plain, Size: 1450 bytes --]

diff --git a/arch/arm64.c b/arch/arm64.c
index 2fd3e18..836ce17 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,8 +292,23 @@ get_versiondep_info_arm64(void)
 		return FALSE;
 	}
 
-	info->page_offset = (0xffffffffffffffffUL) << (va_bits - 1);
+	if (get_num_pt_loads()) {
+		for (i = 0;
+		    get_pt_load(i, &phys_start, NULL, &virt_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;
+			}
+		}
+	}
 
+	info->page_offset = (0xffffffffffffffffUL) << (va_bits - 1);
 	DEBUG_MSG("page_offset=%lx, va_bits=%d\n", info->page_offset,
 			va_bits);
 
diff --git a/makedumpfile.h b/makedumpfile.h
index 5ff94b8..ba85f03 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -542,6 +542,10 @@ do { \
 #ifdef __aarch64__
 unsigned long get_kvbase_arm64(void);
 #define KVBASE			get_kvbase_arm64()
+
+#define __START_KERNEL_map	(0xffffffff80000000UL)
+#define NOT_PADDR_ARM64		(0x0000000010a80000UL)
+
 #endif /* aarch64 */
 
 #ifdef __arm__
-- 
1.8.3.1


[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

_______________________________________________
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

[Bhupesh Sharma]

Hello Kazu,

Many thanks for your review comments.

On Sat, Jul 21, 2018 at 3:18 AM, Kazuhito Hagio <k-hagio@ab.jp.nec.com> 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          4396                    yes             Pages filled
>> with zero
>> NON_PRI_CACHE 27859                   yes             Cache pages
>> without private flag
>> PRI_CACHE     18490                   yes             Cache pages with
>> private flag
>> USER          2728                    yes             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 <bhsharma@redhat.com>
>> ---
>>  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 = (0xffffffffffffffffUL) << (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, &phys_start, NULL, &virt_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      (0x0000000010a80000UL)
>
> 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               (info->page_size / sizeof(unsigned long))
>>
>>  #ifdef __aarch64__
>> +#define __START_KERNEL_map           (0xffffffff80000000UL)
>
> This #ifdef here is for the definitions related to Xen extraction.
> I'll move it to the same place as the above.
>
>>  unsigned long long kvtop_xen_arm64(unsigned long kvaddr);
>>  #define kvtop_xen(X) kvtop_xen_arm64(X)
>>  #endif /* aarch64 */
>>
>
> I attached a patch that was applied my suggestions.
> How about it?

I agree. The patch looks good with the suggested changes.
Please go ahead and feel free to apply the modified patch.

Thanks a lot for your help.
Regards,
Bhupesh

_______________________________________________
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

[Kazuhito Hagio]

Hi Bhupesh,

On 7/22/2018 3:44 AM, Bhupesh Sharma wrote:
> Hello Kazu,
> 
> Many thanks for your review comments.
> 
> On Sat, Jul 21, 2018 at 3:18 AM, Kazuhito Hagio <k-hagio@ab.jp.nec.com> 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          4396                    yes             Pages filled
>>> with zero
>>> NON_PRI_CACHE 27859                   yes             Cache pages
>>> without private flag
>>> PRI_CACHE     18490                   yes             Cache pages with
>>> private flag
>>> USER          2728                    yes             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 <bhsharma@redhat.com>
>>> ---
>>>  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 = (0xffffffffffffffffUL) << (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, &phys_start, NULL, &virt_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      (0x0000000010a80000UL)
>>
>> 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               (info->page_size / sizeof(unsigned long))
>>>
>>>  #ifdef __aarch64__
>>> +#define __START_KERNEL_map           (0xffffffff80000000UL)
>>
>> This #ifdef here is for the definitions related to Xen extraction.
>> I'll move it to the same place as the above.
>>
>>>  unsigned long long kvtop_xen_arm64(unsigned long kvaddr);
>>>  #define kvtop_xen(X) kvtop_xen_arm64(X)
>>>  #endif /* aarch64 */
>>>
>>
>> I attached a patch that was applied my suggestions.
>> How about it?
> 
> I agree. The patch looks good with the suggested changes.
> Please go ahead and feel free to apply the modified patch.

OK, I'll apply it.

With respect to the 2/2 patch, I'm waiting for the kernel patch
to be merged.

If need be, I can apply the 1/2 patch separately from the 2/2 patch,
because I think they are not directly connected with each other.

Thanks,
Kazu

p.s. it seems that I cannot send emails to gmail for now,
so dropped your gmail address. sorry for the inconvenience.

> 
> Thanks a lot for your help.
> Regards,
> Bhupesh
>
_______________________________________________
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

[Bhupesh Sharma]

Hi Kazu,

On Mon, Jul 23, 2018 at 10:15 PM, Kazuhito Hagio <k-hagio@ab.jp.nec.com> wrote:
> Hi Bhupesh,
>
> On 7/22/2018 3:44 AM, Bhupesh Sharma wrote:
>> Hello Kazu,
>>
>> Many thanks for your review comments.
>>
>> On Sat, Jul 21, 2018 at 3:18 AM, Kazuhito Hagio <k-hagio@ab.jp.nec.com> 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          4396                    yes             Pages filled
>>>> with zero
>>>> NON_PRI_CACHE 27859                   yes             Cache pages
>>>> without private flag
>>>> PRI_CACHE     18490                   yes             Cache pages with
>>>> private flag
>>>> USER          2728                    yes             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 <bhsharma@redhat.com>
>>>> ---
>>>>  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 = (0xffffffffffffffffUL) << (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, &phys_start, NULL, &virt_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      (0x0000000010a80000UL)
>>>
>>> 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               (info->page_size / sizeof(unsigned long))
>>>>
>>>>  #ifdef __aarch64__
>>>> +#define __START_KERNEL_map           (0xffffffff80000000UL)
>>>
>>> This #ifdef here is for the definitions related to Xen extraction.
>>> I'll move it to the same place as the above.
>>>
>>>>  unsigned long long kvtop_xen_arm64(unsigned long kvaddr);
>>>>  #define kvtop_xen(X) kvtop_xen_arm64(X)
>>>>  #endif /* aarch64 */
>>>>
>>>
>>> I attached a patch that was applied my suggestions.
>>> How about it?
>>
>> I agree. The patch looks good with the suggested changes.
>> Please go ahead and feel free to apply the modified patch.
>
> OK, I'll apply it.
>
> With respect to the 2/2 patch, I'm waiting for the kernel patch
> to be merged.
>
> If need be, I can apply the 1/2 patch separately from the 2/2 patch,
> because I think they are not directly connected with each other.

Sure, I think we can handle 2/2 patch when it's kernel part is
reviewed properly by the arm64 kernel maintainer(s). We can apply 1/2
patch in the meanwhile.

> p.s. it seems that I cannot send emails to gmail for now,
> so dropped your gmail address. sorry for the inconvenience.

Sure, I use the gmail address just as a backup to read/answer upstream
replies once I am out of office (as it is easier to access on my
phone).

Thanks,
Bhupesh

>>
>> Thanks a lot for your help.
>> Regards,
>> Bhupesh
>>

_______________________________________________
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

[Bhupesh Sharma]

Hi Kazu,

On Tue, Jul 24, 2018 at 10:47 AM, Bhupesh Sharma <bhsharma@redhat.com> wrote:
> Hi Kazu,
>
> On Mon, Jul 23, 2018 at 10:15 PM, Kazuhito Hagio <k-hagio@ab.jp.nec.com> wrote:
>> Hi Bhupesh,
>>
>> On 7/22/2018 3:44 AM, Bhupesh Sharma wrote:
>>> Hello Kazu,
>>>
>>> Many thanks for your review comments.
>>>
>>> On Sat, Jul 21, 2018 at 3:18 AM, Kazuhito Hagio <k-hagio@ab.jp.nec.com> 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          4396                    yes             Pages filled
>>>>> with zero
>>>>> NON_PRI_CACHE 27859                   yes             Cache pages
>>>>> without private flag
>>>>> PRI_CACHE     18490                   yes             Cache pages with
>>>>> private flag
>>>>> USER          2728                    yes             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 <bhsharma@redhat.com>
>>>>> ---
>>>>>  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 = (0xffffffffffffffffUL) << (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, &phys_start, NULL, &virt_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      (0x0000000010a80000UL)
>>>>
>>>> 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               (info->page_size / sizeof(unsigned long))
>>>>>
>>>>>  #ifdef __aarch64__
>>>>> +#define __START_KERNEL_map           (0xffffffff80000000UL)
>>>>
>>>> This #ifdef here is for the definitions related to Xen extraction.
>>>> I'll move it to the same place as the above.
>>>>
>>>>>  unsigned long long kvtop_xen_arm64(unsigned long kvaddr);
>>>>>  #define kvtop_xen(X) kvtop_xen_arm64(X)
>>>>>  #endif /* aarch64 */
>>>>>
>>>>
>>>> I attached a patch that was applied my suggestions.
>>>> How about it?
>>>
>>> I agree. The patch looks good with the suggested changes.
>>> Please go ahead and feel free to apply the modified patch.
>>
>> OK, I'll apply it.
>>
>> With respect to the 2/2 patch, I'm waiting for the kernel patch
>> to be merged.
>>
>> If need be, I can apply the 1/2 patch separately from the 2/2 patch,
>> because I think they are not directly connected with each other.
>
> Sure, I think we can handle 2/2 patch when it's kernel part is
> reviewed properly by the arm64 kernel maintainer(s). We can apply 1/2
> patch in the meanwhile.
>
>> p.s. it seems that I cannot send emails to gmail for now,
>> so dropped your gmail address. sorry for the inconvenience.
>
> Sure, I use the gmail address just as a backup to read/answer upstream
> replies once I am out of office (as it is easier to access on my
> phone).
>
> Thanks,
> Bhupesh

The kernel patch is now accepted in Linus's tree:
commit e401b7c2c69008ad2fcdc154f7c5421281c90042
Author: Bhupesh Sharma <bhsharma@redhat.com>
Date:   Mon Jul 30 11:54:43 2018 +0530

    arm64, kaslr: export offset in VMCOREINFO ELF notes

Can you please pick this patchset and now apply it to makedumpfile source?

Thanks,
Bhupesh

_______________________________________________
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

[Kazuhito Hagio]

Hello Bhupesh,

On 8/15/2018 3:55 PM, Bhupesh Sharma wrote:
> The kernel patch is now accepted in Linus's tree:
> commit e401b7c2c69008ad2fcdc154f7c5421281c90042
> Author: Bhupesh Sharma <bhsharma@redhat.com>
> Date:   Mon Jul 30 11:54:43 2018 +0530
> 
>     arm64, kaslr: export offset in VMCOREINFO ELF notes
> 
> Can you please pick this patchset and now apply it to makedumpfile source?

Thank you for informing me about it, and sorry for my delayed response.
I applied the patches to the devel branch.

commit 616c98d1abac6f348f13cfe55e2df5e1d5d26781
Author: Bhupesh Sharma <bhsharma@redhat.com>
Date:   Thu Jul 19 11:13:41 2018 +0530

    [PATCH] arm64: Add runtime kaslr offset if it exists

commit 94c97db3fe859ca14d7b38b0ae9ee0ffb83689d2
Author: Bhupesh Sharma <bhsharma@redhat.com>
Date:   Thu Jul 19 11:13:40 2018 +0530

    [PATCH] arm64: Get 'info->page_offset' from PT_LOAD segments to support KASLR boot cases

Thanks,
Kazu

> 
> Thanks,
> Bhupesh

_______________________________________________
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

[Bhupesh Sharma]

Hi Kazu,

On Mon, Aug 20, 2018 at 8:54 PM, Kazuhito Hagio <k-hagio@ab.jp.nec.com> wrote:
> Hello Bhupesh,
>
> On 8/15/2018 3:55 PM, Bhupesh Sharma wrote:
>> The kernel patch is now accepted in Linus's tree:
>> commit e401b7c2c69008ad2fcdc154f7c5421281c90042
>> Author: Bhupesh Sharma <bhsharma@redhat.com>
>> Date:   Mon Jul 30 11:54:43 2018 +0530
>>
>>     arm64, kaslr: export offset in VMCOREINFO ELF notes
>>
>> Can you please pick this patchset and now apply it to makedumpfile source?
>
> Thank you for informing me about it, and sorry for my delayed response.
> I applied the patches to the devel branch.
>
> commit 616c98d1abac6f348f13cfe55e2df5e1d5d26781
> Author: Bhupesh Sharma <bhsharma@redhat.com>
> Date:   Thu Jul 19 11:13:41 2018 +0530
>
>     [PATCH] arm64: Add runtime kaslr offset if it exists
>
> commit 94c97db3fe859ca14d7b38b0ae9ee0ffb83689d2
> Author: Bhupesh Sharma <bhsharma@redhat.com>
> Date:   Thu Jul 19 11:13:40 2018 +0530
>
>     [PATCH] arm64: Get 'info->page_offset' from PT_LOAD segments to support KASLR boot cases
>

Thanks. I have sent out another fix for
94c97db3fe859ca14d7b38b0ae9ee0ffb83689d2 here
<http://lists.infradead.org/pipermail/kexec/2018-August/021390.html>,
which removes the
hardcoded NOT_PADDR_ARM64 macro value and makes it platform independent.

Kindly review the same and consider it applying to the makedumpfile
code as well.

Regards,
Bhupesh

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec