[PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled

[PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled

[Pratyush Anand]

Patch 1/4 fixes page_offset calculation, so that it is correctly calculated
on KASLR enabled kernel as well.
Patch 2/4 simplifies VA to PA translation. New code has been benchmarked
against old code on a 4T system.
Patch 3/4 and 4/4 is removal of (now) unnecessary code.

I think, we should find a way to kill find_vememmap() as well, so that
VMEMMAP_START can be removed. I have very limited idea about x86, so unable
to do that as of now.

Pratyush Anand (4):
  x86_64: Calculate page_offset from pt_load
  x86_64: translate all VA to PA using page table values
  x86_64: kill is_vmalloc_addr_x86_64()
  x86_64: kill some unused initialization

 arch/x86_64.c  | 84 ++++++++++++++++++++--------------------------------------
 makedumpfile.h |  9 +++----
 2 files changed, 32 insertions(+), 61 deletions(-)

-- 
2.7.4


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

Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled

[Louis Bouchard]

Hello,

Le 24/10/2016 à 18:48, Pratyush Anand a écrit :
> Patch 1/4 fixes page_offset calculation, so that it is correctly calculated
> on KASLR enabled kernel as well.
> Patch 2/4 simplifies VA to PA translation. New code has been benchmarked
> against old code on a 4T system.
> Patch 3/4 and 4/4 is removal of (now) unnecessary code.
> 
> I think, we should find a way to kill find_vememmap() as well, so that
> VMEMMAP_START can be removed. I have very limited idea about x86, so unable
> to do that as of now.
> 
> Pratyush Anand (4):
>   x86_64: Calculate page_offset from pt_load
>   x86_64: translate all VA to PA using page table values
>   x86_64: kill is_vmalloc_addr_x86_64()
>   x86_64: kill some unused initialization
> 
>  arch/x86_64.c  | 84 ++++++++++++++++++++--------------------------------------
>  makedumpfile.h |  9 +++----
>  2 files changed, 32 insertions(+), 61 deletions(-)
> 

Cross-posting but FYI, this patch fixes the issue reported in the following
thread : makedumpfile issues many readpage_elf: Attempt to read non-existent page[1]

It corresponds to the commit identified by my kernel bisection.

I will wait until it is accepted in Kumagai-san's tree to include it in
Debian/Ubuntu.

Kind regards,

...Louis

[1] https://www.mail-archive.com/kexec@lists.infradead.org/msg16434.html
-- 
Louis Bouchard
Software engineer, Cloud & Sustaining eng.
Canonical Ltd
Ubuntu developer                       Debian Maintainer
GPG : 429D 7A3B DD05 B6F8 AF63  B9C4 8B3D 867C 823E 7A61

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

Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled

[Pratyush Anand]

Hi Louis,

On Tue, Oct 25, 2016 at 2:47 PM, Louis Bouchard
<louis.bouchard@canonical.com> wrote:
> Hello,
>
> Le 24/10/2016 à 18:48, Pratyush Anand a écrit :
>> Patch 1/4 fixes page_offset calculation, so that it is correctly calculated
>> on KASLR enabled kernel as well.
>> Patch 2/4 simplifies VA to PA translation. New code has been benchmarked
>> against old code on a 4T system.
>> Patch 3/4 and 4/4 is removal of (now) unnecessary code.
>>
>> I think, we should find a way to kill find_vememmap() as well, so that
>> VMEMMAP_START can be removed. I have very limited idea about x86, so unable
>> to do that as of now.
>>
>> Pratyush Anand (4):
>>   x86_64: Calculate page_offset from pt_load
>>   x86_64: translate all VA to PA using page table values
>>   x86_64: kill is_vmalloc_addr_x86_64()
>>   x86_64: kill some unused initialization
>>
>>  arch/x86_64.c  | 84 ++++++++++++++++++++--------------------------------------
>>  makedumpfile.h |  9 +++----
>>  2 files changed, 32 insertions(+), 61 deletions(-)
>>
>
> Cross-posting but FYI, this patch fixes the issue reported in the following
> thread : makedumpfile issues many readpage_elf: Attempt to read non-existent page[1]
>
> It corresponds to the commit identified by my kernel bisection.
>
> I will wait until it is accepted in Kumagai-san's tree to include it in
> Debian/Ubuntu.

Thanks a lot for your testing.

~Pratyush

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

Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled

[Dave Young]

Hi Pratyush,

On 10/24/16 at 10:18pm, Pratyush Anand wrote:
> Patch 1/4 fixes page_offset calculation, so that it is correctly calculated
> on KASLR enabled kernel as well.
> Patch 2/4 simplifies VA to PA translation. New code has been benchmarked
> against old code on a 4T system.
> Patch 3/4 and 4/4 is removal of (now) unnecessary code.
> 
> I think, we should find a way to kill find_vememmap() as well, so that
> VMEMMAP_START can be removed. I have very limited idea about x86, so unable
> to do that as of now.
> 
> Pratyush Anand (4):
>   x86_64: Calculate page_offset from pt_load
>   x86_64: translate all VA to PA using page table values
>   x86_64: kill is_vmalloc_addr_x86_64()
>   x86_64: kill some unused initialization
> 
>  arch/x86_64.c  | 84 ++++++++++++++++++++--------------------------------------
>  makedumpfile.h |  9 +++----
>  2 files changed, 32 insertions(+), 61 deletions(-)
> 

According to our test, with these patches the dumped vmcore is correct
which means simple crash test `bt` works. But the saved vmcore size is
larger than before.

I collected two --message-level 31 logs with/without your patches, the
kernel kaslr was disabled during my test so that we can focus on the
vmcore size issue, it looks like mem_map address was not collected
correctly.

[please ignore the patched log extra debug message I added] 

--- unpatched-makedumpfile.txt	2016-10-27 10:31:34.152962407 +0800
+++ patched-makedumpfile.txt	2016-10-27 10:28:44.213952179 +0800
@@ -1,4 +1,4 @@
-[127.0.0.1-2016-10-27-10:27:03]# /tmp/makedumpfile -l -d 31 --message-level 31 vmcore vmcore.m.1
+[127.0.0.1-2016-10-27-10:27:03]# /home/dyoung/git/makedumpfile/makedumpfile -l -d 31 --message-level 31 vmcore vmcore.m
 sadump: does not have partition header
 sadump: read dump device as unknown format
 sadump: unknown format
@@ -36,70 +36,76 @@
 
 Memory type  : SPARSEMEM_EX
 
+printing memmap .....
 mem_map (0)
-  mem_map    : ffffea0000000000
+  mem_map    : 0
   pfn_start  : 0
   pfn_end    : 8000
+printing memmap .....
 mem_map (1)
-  mem_map    : ffffea0000200000
+  mem_map    : 0
   pfn_start  : 8000
   pfn_end    : 10000
+printing memmap .....
 mem_map (2)
-  mem_map    : ffffea0000400000
+  mem_map    : 0
   pfn_start  : 10000
   pfn_end    : 18000
+printing memmap .....
 mem_map (3)
-  mem_map    : ffffea0000600000
+  mem_map    : 0
   pfn_start  : 18000
   pfn_end    : 20000
+printing memmap .....
 mem_map (4)
-  mem_map    : ffffea0000800000
+  mem_map    : 0
   pfn_start  : 20000
   pfn_end    : 28000
+printing memmap .....
 mem_map (5)
-  mem_map    : ffffea0000a00000
+  mem_map    : 0
   pfn_start  : 28000
   pfn_end    : 30000
+printing memmap .....
 mem_map (6)
-  mem_map    : ffffea0000c00000
+  mem_map    : 0
   pfn_start  : 30000
   pfn_end    : 38000
+printing memmap .....
 mem_map (7)
-  mem_map    : ffffea0000e00000
+  mem_map    : 0
   pfn_start  : 38000
   pfn_end    : 3ffda
 mmap() is available on the kernel.
 Checking for memory holes          : [100.0 %] |STEP [Checking for memory holes  ] : 0.000030 seconds
-Excluding unnecessary pages        : [100.0 %] \STEP [Excluding unnecessary pages] : 0.007547 seconds
-Checking for memory holes          : [100.0 %] -STEP [Checking for memory holes  ] : 0.000016 seconds
-Checking for memory holes          : [100.0 %] /STEP [Checking for memory holes  ] : 0.000009 seconds
-Excluding unnecessary pages        : [100.0 %] |STEP [Excluding unnecessary pages] : 0.006623 seconds
-Copying data                       : [100.0 %] \STEP [Copying data               ] : 0.184442 seconds
-Copying data                       : [100.0 %] -STEP [Copying data               ] : 0.000041 seconds
+Excluding unnecessary pages        : [100.0 %] \STEP [Excluding unnecessary pages] : 0.000007 seconds
+Checking for memory holes          : [100.0 %] -STEP [Checking for memory holes  ] : 0.000014 seconds
+Checking for memory holes          : [100.0 %] /STEP [Checking for memory holes  ] : 0.000008 seconds
+Excluding unnecessary pages        : [100.0 %] |STEP [Excluding unnecessary pages] : 0.000007 seconds
+Copying data                       : [100.0 %] /STEP [Copying data               ] : 1.421661 seconds
+Copying data                       : [100.0 %] |STEP [Copying data               ] : 0.000036 seconds
 
 Writing erase info...
-offset_eraseinfo: dd5c4e, size_eraseinfo: 0
+offset_eraseinfo: 888c149, size_eraseinfo: 0
 
 Original pages  : 0x0000000000030c7d
-  Excluded pages   : 0x000000000002cf58
-    Pages filled with zero  : 0x00000000000002be
-    Non-private cache pages : 0x0000000000006574
-    Private cache pages     : 0x0000000000000f27
-    User process data pages : 0x0000000000003481
-    Free pages              : 0x000000000002237e
+  Excluded pages   : 0x000000000001d534
+    Pages filled with zero  : 0x000000000001d534
+    Non-private cache pages : 0x0000000000000000
+    Private cache pages     : 0x0000000000000000
+    User process data pages : 0x0000000000000000
+    Free pages              : 0x0000000000000000
     Hwpoison pages          : 0x0000000000000000
-  Remaining pages  : 0x0000000000003d25
-  (The number of pages is reduced to 7%.)
+  Remaining pages  : 0x0000000000013749
+  (The number of pages is reduced to 39%.)
 Memory Hole     : 0x000000000000f35d
 --------------------------------------------------
 Total pages     : 0x000000000003ffda
 
-Cache hit: 29946, miss: 47, hit rate: 99.8%
+Cache hit: 196285, miss: 201, hit rate: 99.9%
 
 
-The dumpfile is saved to vmcore.m.1.
+The dumpfile is saved to vmcore.m.
 
 makedumpfile Completed.
-[root@dhcp-128-65 127.0.0.1-2016-10-27-10:27:03]# ls -lth vmcore.m*
--rw------- 1 root root  14M Oct 27 10:30 vmcore.m.1
--rw------- 1 root root 137M Oct 27 10:28 vmcore.m
+[root@dhcp-128-65 127.0.0.1-2016-10-27-10:27:03]# 

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

Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled

[Dave Young]

I put the cped-vmcore/vmlinux here:
https://people.redhat.com/~ruyang/test/

Adding Dave Anderson for any comments about the vmcore correctness from
crash point of view..

On 10/27/16 at 10:37am, Dave Young wrote:
> Hi Pratyush,
> 
> On 10/24/16 at 10:18pm, Pratyush Anand wrote:
> > Patch 1/4 fixes page_offset calculation, so that it is correctly calculated
> > on KASLR enabled kernel as well.
> > Patch 2/4 simplifies VA to PA translation. New code has been benchmarked
> > against old code on a 4T system.
> > Patch 3/4 and 4/4 is removal of (now) unnecessary code.
> > 
> > I think, we should find a way to kill find_vememmap() as well, so that
> > VMEMMAP_START can be removed. I have very limited idea about x86, so unable
> > to do that as of now.
> > 
> > Pratyush Anand (4):
> >   x86_64: Calculate page_offset from pt_load
> >   x86_64: translate all VA to PA using page table values
> >   x86_64: kill is_vmalloc_addr_x86_64()
> >   x86_64: kill some unused initialization
> > 
> >  arch/x86_64.c  | 84 ++++++++++++++++++++--------------------------------------
> >  makedumpfile.h |  9 +++----
> >  2 files changed, 32 insertions(+), 61 deletions(-)
> > 
> 
> According to our test, with these patches the dumped vmcore is correct
> which means simple crash test `bt` works. But the saved vmcore size is
> larger than before.
> 
> I collected two --message-level 31 logs with/without your patches, the
> kernel kaslr was disabled during my test so that we can focus on the
> vmcore size issue, it looks like mem_map address was not collected
> correctly.
> 
> [please ignore the patched log extra debug message I added] 
> 
> --- unpatched-makedumpfile.txt	2016-10-27 10:31:34.152962407 +0800
> +++ patched-makedumpfile.txt	2016-10-27 10:28:44.213952179 +0800
> @@ -1,4 +1,4 @@
> -[127.0.0.1-2016-10-27-10:27:03]# /tmp/makedumpfile -l -d 31 --message-level 31 vmcore vmcore.m.1
> +[127.0.0.1-2016-10-27-10:27:03]# /home/dyoung/git/makedumpfile/makedumpfile -l -d 31 --message-level 31 vmcore vmcore.m
>  sadump: does not have partition header
>  sadump: read dump device as unknown format
>  sadump: unknown format
> @@ -36,70 +36,76 @@
>  
>  Memory type  : SPARSEMEM_EX
>  
> +printing memmap .....
>  mem_map (0)
> -  mem_map    : ffffea0000000000
> +  mem_map    : 0
>    pfn_start  : 0
>    pfn_end    : 8000
> +printing memmap .....
>  mem_map (1)
> -  mem_map    : ffffea0000200000
> +  mem_map    : 0
>    pfn_start  : 8000
>    pfn_end    : 10000
> +printing memmap .....
>  mem_map (2)
> -  mem_map    : ffffea0000400000
> +  mem_map    : 0
>    pfn_start  : 10000
>    pfn_end    : 18000
> +printing memmap .....
>  mem_map (3)
> -  mem_map    : ffffea0000600000
> +  mem_map    : 0
>    pfn_start  : 18000
>    pfn_end    : 20000
> +printing memmap .....
>  mem_map (4)
> -  mem_map    : ffffea0000800000
> +  mem_map    : 0
>    pfn_start  : 20000
>    pfn_end    : 28000
> +printing memmap .....
>  mem_map (5)
> -  mem_map    : ffffea0000a00000
> +  mem_map    : 0
>    pfn_start  : 28000
>    pfn_end    : 30000
> +printing memmap .....
>  mem_map (6)
> -  mem_map    : ffffea0000c00000
> +  mem_map    : 0
>    pfn_start  : 30000
>    pfn_end    : 38000
> +printing memmap .....
>  mem_map (7)
> -  mem_map    : ffffea0000e00000
> +  mem_map    : 0
>    pfn_start  : 38000
>    pfn_end    : 3ffda
>  mmap() is available on the kernel.
>  Checking for memory holes          : [100.0 %] |STEP [Checking for memory holes  ] : 0.000030 seconds
> -Excluding unnecessary pages        : [100.0 %] \STEP [Excluding unnecessary pages] : 0.007547 seconds
> -Checking for memory holes          : [100.0 %] -STEP [Checking for memory holes  ] : 0.000016 seconds
> -Checking for memory holes          : [100.0 %] /STEP [Checking for memory holes  ] : 0.000009 seconds
> -Excluding unnecessary pages        : [100.0 %] |STEP [Excluding unnecessary pages] : 0.006623 seconds
> -Copying data                       : [100.0 %] \STEP [Copying data               ] : 0.184442 seconds
> -Copying data                       : [100.0 %] -STEP [Copying data               ] : 0.000041 seconds
> +Excluding unnecessary pages        : [100.0 %] \STEP [Excluding unnecessary pages] : 0.000007 seconds
> +Checking for memory holes          : [100.0 %] -STEP [Checking for memory holes  ] : 0.000014 seconds
> +Checking for memory holes          : [100.0 %] /STEP [Checking for memory holes  ] : 0.000008 seconds
> +Excluding unnecessary pages        : [100.0 %] |STEP [Excluding unnecessary pages] : 0.000007 seconds
> +Copying data                       : [100.0 %] /STEP [Copying data               ] : 1.421661 seconds
> +Copying data                       : [100.0 %] |STEP [Copying data               ] : 0.000036 seconds
>  
>  Writing erase info...
> -offset_eraseinfo: dd5c4e, size_eraseinfo: 0
> +offset_eraseinfo: 888c149, size_eraseinfo: 0
>  
>  Original pages  : 0x0000000000030c7d
> -  Excluded pages   : 0x000000000002cf58
> -    Pages filled with zero  : 0x00000000000002be
> -    Non-private cache pages : 0x0000000000006574
> -    Private cache pages     : 0x0000000000000f27
> -    User process data pages : 0x0000000000003481
> -    Free pages              : 0x000000000002237e
> +  Excluded pages   : 0x000000000001d534
> +    Pages filled with zero  : 0x000000000001d534
> +    Non-private cache pages : 0x0000000000000000
> +    Private cache pages     : 0x0000000000000000
> +    User process data pages : 0x0000000000000000
> +    Free pages              : 0x0000000000000000
>      Hwpoison pages          : 0x0000000000000000
> -  Remaining pages  : 0x0000000000003d25
> -  (The number of pages is reduced to 7%.)
> +  Remaining pages  : 0x0000000000013749
> +  (The number of pages is reduced to 39%.)
>  Memory Hole     : 0x000000000000f35d
>  --------------------------------------------------
>  Total pages     : 0x000000000003ffda
>  
> -Cache hit: 29946, miss: 47, hit rate: 99.8%
> +Cache hit: 196285, miss: 201, hit rate: 99.9%
>  
>  
> -The dumpfile is saved to vmcore.m.1.
> +The dumpfile is saved to vmcore.m.
>  
>  makedumpfile Completed.
> -[root@dhcp-128-65 127.0.0.1-2016-10-27-10:27:03]# ls -lth vmcore.m*
> --rw------- 1 root root  14M Oct 27 10:30 vmcore.m.1
> --rw------- 1 root root 137M Oct 27 10:28 vmcore.m
> +[root@dhcp-128-65 127.0.0.1-2016-10-27-10:27:03]# 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

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

Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled

[Baoquan He]

On 10/27/16 at 10:37am, Dave Young wrote:
> Hi Pratyush,
> 
> On 10/24/16 at 10:18pm, Pratyush Anand wrote:
> > Patch 1/4 fixes page_offset calculation, so that it is correctly calculated
> > on KASLR enabled kernel as well.
> > Patch 2/4 simplifies VA to PA translation. New code has been benchmarked
> > against old code on a 4T system.
> > Patch 3/4 and 4/4 is removal of (now) unnecessary code.
> > 
> > I think, we should find a way to kill find_vememmap() as well, so that
> > VMEMMAP_START can be removed. I have very limited idea about x86, so unable
> > to do that as of now.
> > 
> > Pratyush Anand (4):
> >   x86_64: Calculate page_offset from pt_load
> >   x86_64: translate all VA to PA using page table values
> >   x86_64: kill is_vmalloc_addr_x86_64()
> >   x86_64: kill some unused initialization
> > 
> >  arch/x86_64.c  | 84 ++++++++++++++++++++--------------------------------------
> >  makedumpfile.h |  9 +++----
> >  2 files changed, 32 insertions(+), 61 deletions(-)
> > 
> 
> According to our test, with these patches the dumped vmcore is correct
> which means simple crash test `bt` works. But the saved vmcore size is
> larger than before.
> 
> I collected two --message-level 31 logs with/without your patches, the
> kernel kaslr was disabled during my test so that we can focus on the
> vmcore size issue, it looks like mem_map address was not collected
> correctly.

From printing log, this is not correct. Without memmap, filtering can't
be done correctly. 

> 
> [please ignore the patched log extra debug message I added] 
> 
> --- unpatched-makedumpfile.txt	2016-10-27 10:31:34.152962407 +0800
> +++ patched-makedumpfile.txt	2016-10-27 10:28:44.213952179 +0800
> @@ -1,4 +1,4 @@
> -[127.0.0.1-2016-10-27-10:27:03]# /tmp/makedumpfile -l -d 31 --message-level 31 vmcore vmcore.m.1
> +[127.0.0.1-2016-10-27-10:27:03]# /home/dyoung/git/makedumpfile/makedumpfile -l -d 31 --message-level 31 vmcore vmcore.m
>  sadump: does not have partition header
>  sadump: read dump device as unknown format
>  sadump: unknown format
> @@ -36,70 +36,76 @@
>  
>  Memory type  : SPARSEMEM_EX
>  
> +printing memmap .....
>  mem_map (0)
> -  mem_map    : ffffea0000000000
> +  mem_map    : 0
>    pfn_start  : 0
>    pfn_end    : 8000
> +printing memmap .....
>  mem_map (1)
> -  mem_map    : ffffea0000200000
> +  mem_map    : 0
>    pfn_start  : 8000
>    pfn_end    : 10000
> +printing memmap .....
>  mem_map (2)
> -  mem_map    : ffffea0000400000
> +  mem_map    : 0
>    pfn_start  : 10000
>    pfn_end    : 18000
> +printing memmap .....
>  mem_map (3)
> -  mem_map    : ffffea0000600000
> +  mem_map    : 0
>    pfn_start  : 18000
>    pfn_end    : 20000
> +printing memmap .....
>  mem_map (4)
> -  mem_map    : ffffea0000800000
> +  mem_map    : 0
>    pfn_start  : 20000
>    pfn_end    : 28000
> +printing memmap .....
>  mem_map (5)
> -  mem_map    : ffffea0000a00000
> +  mem_map    : 0
>    pfn_start  : 28000
>    pfn_end    : 30000
> +printing memmap .....
>  mem_map (6)
> -  mem_map    : ffffea0000c00000
> +  mem_map    : 0
>    pfn_start  : 30000
>    pfn_end    : 38000
> +printing memmap .....
>  mem_map (7)
> -  mem_map    : ffffea0000e00000
> +  mem_map    : 0
>    pfn_start  : 38000
>    pfn_end    : 3ffda
>  mmap() is available on the kernel.
>  Checking for memory holes          : [100.0 %] |STEP [Checking for memory holes  ] : 0.000030 seconds
> -Excluding unnecessary pages        : [100.0 %] \STEP [Excluding unnecessary pages] : 0.007547 seconds
> -Checking for memory holes          : [100.0 %] -STEP [Checking for memory holes  ] : 0.000016 seconds
> -Checking for memory holes          : [100.0 %] /STEP [Checking for memory holes  ] : 0.000009 seconds
> -Excluding unnecessary pages        : [100.0 %] |STEP [Excluding unnecessary pages] : 0.006623 seconds
> -Copying data                       : [100.0 %] \STEP [Copying data               ] : 0.184442 seconds
> -Copying data                       : [100.0 %] -STEP [Copying data               ] : 0.000041 seconds
> +Excluding unnecessary pages        : [100.0 %] \STEP [Excluding unnecessary pages] : 0.000007 seconds
> +Checking for memory holes          : [100.0 %] -STEP [Checking for memory holes  ] : 0.000014 seconds
> +Checking for memory holes          : [100.0 %] /STEP [Checking for memory holes  ] : 0.000008 seconds
> +Excluding unnecessary pages        : [100.0 %] |STEP [Excluding unnecessary pages] : 0.000007 seconds
> +Copying data                       : [100.0 %] /STEP [Copying data               ] : 1.421661 seconds
> +Copying data                       : [100.0 %] |STEP [Copying data               ] : 0.000036 seconds
>  
>  Writing erase info...
> -offset_eraseinfo: dd5c4e, size_eraseinfo: 0
> +offset_eraseinfo: 888c149, size_eraseinfo: 0
>  
>  Original pages  : 0x0000000000030c7d
> -  Excluded pages   : 0x000000000002cf58
> -    Pages filled with zero  : 0x00000000000002be
> -    Non-private cache pages : 0x0000000000006574
> -    Private cache pages     : 0x0000000000000f27
> -    User process data pages : 0x0000000000003481
> -    Free pages              : 0x000000000002237e
> +  Excluded pages   : 0x000000000001d534
> +    Pages filled with zero  : 0x000000000001d534
> +    Non-private cache pages : 0x0000000000000000
> +    Private cache pages     : 0x0000000000000000
> +    User process data pages : 0x0000000000000000
> +    Free pages              : 0x0000000000000000
>      Hwpoison pages          : 0x0000000000000000
> -  Remaining pages  : 0x0000000000003d25
> -  (The number of pages is reduced to 7%.)
> +  Remaining pages  : 0x0000000000013749
> +  (The number of pages is reduced to 39%.)
>  Memory Hole     : 0x000000000000f35d
>  --------------------------------------------------
>  Total pages     : 0x000000000003ffda
>  
> -Cache hit: 29946, miss: 47, hit rate: 99.8%
> +Cache hit: 196285, miss: 201, hit rate: 99.9%
>  
>  
> -The dumpfile is saved to vmcore.m.1.
> +The dumpfile is saved to vmcore.m.
>  
>  makedumpfile Completed.
> -[root@dhcp-128-65 127.0.0.1-2016-10-27-10:27:03]# ls -lth vmcore.m*
> --rw------- 1 root root  14M Oct 27 10:30 vmcore.m.1
> --rw------- 1 root root 137M Oct 27 10:28 vmcore.m
> +[root@dhcp-128-65 127.0.0.1-2016-10-27-10:27:03]# 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

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

Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled

[Pratyush Anand]

On Thursday 27 October 2016 08:07 AM, Dave Young wrote:
> According to our test, with these patches the dumped vmcore is correct
> which means simple crash test `bt` works. But the saved vmcore size is
> larger than before.
>
> I collected two --message-level 31 logs with/without your patches, the
> kernel kaslr was disabled during my test so that we can focus on the
> vmcore size issue, it looks like mem_map address was not collected
> correctly.
>
> [please ignore the patched log extra debug message I added]

Hummm..thanks for pointing it out.

Seems patch 1/4 is wrong.

with this patch page_offset = ffffffff80000000
while with original code page_offset = ffff880000000000

Trying to see where it is wrong

~Pratyush

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

Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled

[Dave Young]

On 10/27/16 at 10:54am, Dave Young wrote:
> I put the cped-vmcore/vmlinux here:
> https://people.redhat.com/~ruyang/test/
> 
> Adding Dave Anderson for any comments about the vmcore correctness from
> crash point of view..
> 

Since the reason has been found, the page_offset was not correct, I
tested with a changed version of patch 1, it works. Please ignore the
test vmcore, I deleted them.

Here is a new tarball which could be used by Dave to verify the kaslr, I
enabled kaslr, also saved vmlinux/cped vmcore/makedumpfile saved vmcore
in a tarball below.
http://people.redhat.com/~ruyang/test/vmcore-test.tar.gz

Thanks
Dave

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

Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled

[Dave Anderson]

----- Original Message -----
> 
> I put the cped-vmcore/vmlinux here:
> https://people.redhat.com/~ruyang/test/
> 
> Adding Dave Anderson for any comments about the vmcore correctness from
> crash point of view..
> 

As it turns out, the vmcore.makedumpfile can be read just fine:

  $ crash vmlinux.kaslr vmcore.makedumpfile 
  
  crash 7.1.7rc9
  Copyright (C) 2002-2016  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.
   
  GNU gdb (GDB) 7.6
  Copyright (C) 2013 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "x86_64-unknown-linux-gnu"...
  
  WARNING: kernel relocated [602MB]: patching 55325 gdb minimal_symbol values
  
        KERNEL: vmlinux.kaslr                                            
      DUMPFILE: vmcore.makedumpfile  [PARTIAL DUMP]
          CPUS: 1
          DATE: Thu Oct 27 02:07:46 2016
        UPTIME: 00:00:41
  LOAD AVERAGE: 0.14, 0.04, 0.01
         TASKS: 107
      NODENAME: localhost.localdomain
       RELEASE: 4.9.0-rc2+
       VERSION: #185 SMP Wed Oct 26 11:23:54 CST 2016
       MACHINE: x86_64  (2294 Mhz)
        MEMORY: 1 GB
         PANIC: "sysrq: SysRq : Trigger a crash"
           PID: 1934
       COMMAND: "bash"
          TASK: ffff9ca3bc155e00  [THREAD_INFO: ffff9ca3bc155e00]
           CPU: 0
         STATE: TASK_RUNNING (SYSRQ)
  
  crash> bt
  PID: 1934   TASK: ffff9ca3bc155e00  CPU: 0   COMMAND: "bash"
   #0 [ffffb2df4033fa08] machine_kexec at ffffffffa6a34e09
   #1 [ffffb2df4033fa68] __crash_kexec at ffffffffa6ab945a
   #2 [ffffb2df4033fb30] __crash_kexec at ffffffffa6ab9530
   #3 [ffffb2df4033fb48] crash_kexec at ffffffffa6ab9576
   #4 [ffffb2df4033fb68] oops_end at ffffffffa6a1529f
   #5 [ffffb2df4033fb90] no_context at ffffffffa6a3f67b
   #6 [ffffb2df4033fbf8] __bad_area_nosemaphore at ffffffffa6a3f8cc
   #7 [ffffb2df4033fc48] bad_area at ffffffffa6a3fa71
   #8 [ffffb2df4033fc70] __do_page_fault at ffffffffa6a4004d
   #9 [ffffb2df4033fcd8] do_page_fault at ffffffffa6a40100
  #10 [ffffb2df4033fd08] do_async_page_fault at ffffffffa6a3bbc5
  #11 [ffffb2df4033fd20] async_page_fault at ffffffffa6f9f1e5
      [exception RIP: sysrq_handle_crash+17]
      RIP: ffffffffa6d3a101  RSP: ffffb2df4033fdd8  RFLAGS: 00010282
      RAX: 000000000000000f  RBX: 0000000000000063  RCX: 0000000000000000
      RDX: 0000000000000000  RSI: ffff9ca3be60cc28  RDI: 0000000000000063
      RBP: ffffb2df4033fdd8   R8: 0000000000000001   R9: 0000000000000006
      R10: 0000000000000001  R11: 0000000000000172  R12: 0000000000000007
      R13: 0000000000000000  R14: ffffffffa745b4a0  R15: 0000000000000000
      ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
  #12 [ffffb2df4033fde0] __handle_sysrq at ffffffffa6d3a821
  #13 [ffffb2df4033fe10] write_sysrq_trigger at ffffffffa6d3ac4a
  #14 [ffffb2df4033fe28] proc_reg_write at ffffffffa6bb73dd
  #15 [ffffb2df4033fe48] __vfs_write at ffffffffa6b55b02
  #16 [ffffb2df4033fed0] vfs_write at ffffffffa6b56dbc
  #17 [ffffb2df4033ff08] sys_write at ffffffffa6b58060
  #18 [ffffb2df4033ff50] entry_SYSCALL_64_fastpath at ffffffffa6f9dbbb
      RIP: 00007f0b401a9c20  RSP: 00007ffe38d75698  RFLAGS: 00000246
      RAX: ffffffffffffffda  RBX: 0000000000000000  RCX: 00007f0b401a9c20
      RDX: 0000000000000002  RSI: 00005577bf7de790  RDI: 0000000000000001
      RBP: 0000000000000001   R8: 00007f0b40474740   R9: 00007f0b40ab7b40
      R10: 0000000000000073  R11: 0000000000000246  R12: 0000000000000000
      R13: 00007ffe38d75c10  R14: 0000000000000000  R15: 0000000000000000
      ORIG_RAX: 0000000000000001  CS: 0033  SS: 002b
  crash> 
  
But the ELF vmcore fails:
  
  $ crash vmlinux.kaslr vmcore
  
  crash 7.1.7rc9
  Copyright (C) 2002-2016  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.
   
  GNU gdb (GDB) 7.6
  Copyright (C) 2013 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "x86_64-unknown-linux-gnu"...
  
  WARNING: kernel relocated [602MB]: patching 55325 gdb minimal_symbol values
  
  WARNING: could not find MAGIC_START!                                   
  WARNING: cannot read linux_banner string
  crash: vmlinux.kaslr and vmcore do not match!
  
  Usage:
  
    crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS]	(dumpfile form)
    crash [OPTION]... [NAMELIST]             		(live system form)
  
  Enter "crash -h" for details.
  $
  
Since the data being read was bogus, the first thing I checked was whether
the phys_base value was being calculated correctly.  I manually applied 
the phys_base that was stored in the compressed dump header, and the ELF
vmcore can be read:

  $ crash --machdep phys_base=ffffffffdf400000 vmlinux.kaslr vmcore 
  
  crash 7.1.7rc9
  Copyright (C) 2002-2016  Red Hat, Inc.
  Copyright (C) 2004, 2005, 2006, 2010  IBM Corporation
  Copyright (C) 1999-2006  Hewlett-Packard Co
  Copyright (C) 2005, 2006, 2011, 2012  Fujitsu Limited
  Copyright (C) 2006, 2007  VA Linux Systems Japan K.K.
  Copyright (C) 2005, 2011  NEC Corporation
  Copyright (C) 1999, 2002, 2007  Silicon Graphics, Inc.
  Copyright (C) 1999, 2000, 2001, 2002  Mission Critical Linux, Inc.
  This program is free software, covered by the GNU General Public License,
  and you are welcome to change it and/or distribute copies of it under
  certain conditions.  Enter "help copying" to see the conditions.
  This program has absolutely no warranty.  Enter "help warranty" for details.
   
  NOTE: setting phys_base to: 0xffffffffdf400000
  
  GNU gdb (GDB) 7.6
  Copyright (C) 2013 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
  and "show warranty" for details.
  This GDB was configured as "x86_64-unknown-linux-gnu"...
  
  WARNING: kernel relocated [602MB]: patching 55325 gdb minimal_symbol values
  
        KERNEL: vmlinux.kaslr                                            
      DUMPFILE: vmcore
          CPUS: 1
          DATE: Thu Oct 27 02:07:46 2016
        UPTIME: 00:00:41
  LOAD AVERAGE: 0.14, 0.04, 0.01
         TASKS: 107
      NODENAME: localhost.localdomain
       RELEASE: 4.9.0-rc2+
       VERSION: #185 SMP Wed Oct 26 11:23:54 CST 2016
       MACHINE: x86_64  (2294 Mhz)
        MEMORY: 1 GB
         PANIC: "sysrq: SysRq : Trigger a crash"
           PID: 1934
       COMMAND: "bash"
          TASK: ffff9ca3bc155e00  [THREAD_INFO: ffff9ca3bc155e00]
           CPU: 0
         STATE: TASK_RUNNING (SYSRQ)
  
  crash> 
  
That being said, my recent 4.8 and 4.9 KASLR testing has been on live
systems and compressed kdumps, so the old tried-and-true manner of
calculating the phys_base from the ELF PT_LOAD segments apparently
no longer works with KASLR.  

It would be so much more helpful if the VMCOREINFO data in the ELF 
header stored the actual phys_base value instead of its symbol value:

  crash> help -D
  ...
  SYMBOL(phys_base)=ffffffffa740b010
  ...

which is completely useless unless the phys_base value is known.

Anyway, can you send me the makedumpfile code that calculates the 
phys_base value?

Dave

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

Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled

[Dave Anderson]

----- Original Message -----

>   
> That being said, my recent 4.8 and 4.9 KASLR testing has been on live
> systems and compressed kdumps, so the old tried-and-true manner of
> calculating the phys_base from the ELF PT_LOAD segments apparently
> no longer works with KASLR.
> 
> It would be so much more helpful if the VMCOREINFO data in the ELF
> header stored the actual phys_base value instead of its symbol value:
> 
>   crash> help -D
>   ...
>   SYMBOL(phys_base)=ffffffffa740b010
>   ...
> 
> which is completely useless unless the phys_base value is known.
> 
> Anyway, can you send me the makedumpfile code that calculates the
> phys_base value?
> 
> Dave

As it turns out, the problem with the crash utility is that it has to
calculate phys_base well before it even knows the kernel has been relocated 
by KASLR.  So when it sees the __START_KERNEL_map PT_LOAD segment, it mistakes
it for the kernel modules' virtual address region and skips it.

The kernel has this:

  #if defined(CONFIG_RANDOMIZE_BASE)
  #define KERNEL_IMAGE_SIZE       (1024 * 1024 * 1024)
  #else
  #define KERNEL_IMAGE_SIZE       (512 * 1024 * 1024)
  #endif

and then this:

  #define MODULES_VADDR    (__START_KERNEL_map + KERNEL_IMAGE_SIZE)

So with KASLR, MODULES_VADDR gets pushed up from the traditional ffffffffa0000000
up to ffffffffc0000000.

So I'm curious as to what you use in makedumpfile to determine whether 
CONFIG_RANDOMIZE_BASE has been configured?

Thanks,
  Dave



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

Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled

[Dave Anderson]

----- Original Message -----
> 
> 
> ----- Original Message -----
> 
> >   
> > That being said, my recent 4.8 and 4.9 KASLR testing has been on live
> > systems and compressed kdumps, so the old tried-and-true manner of
> > calculating the phys_base from the ELF PT_LOAD segments apparently
> > no longer works with KASLR.
> > 
> > It would be so much more helpful if the VMCOREINFO data in the ELF
> > header stored the actual phys_base value instead of its symbol value:
> > 
> >   crash> help -D
> >   ...
> >   SYMBOL(phys_base)=ffffffffa740b010
> >   ...
> > 
> > which is completely useless unless the phys_base value is known.
> > 
> > Anyway, can you send me the makedumpfile code that calculates the
> > phys_base value?
> > 
> > Dave
> 
> As it turns out, the problem with the crash utility is that it has to
> calculate phys_base well before it even knows the kernel has been relocated
> by KASLR.  So when it sees the __START_KERNEL_map PT_LOAD segment, it
> mistakes
> it for the kernel modules' virtual address region and skips it.
> 
> The kernel has this:
> 
>   #if defined(CONFIG_RANDOMIZE_BASE)
>   #define KERNEL_IMAGE_SIZE       (1024 * 1024 * 1024)
>   #else
>   #define KERNEL_IMAGE_SIZE       (512 * 1024 * 1024)
>   #endif
> 
> and then this:
> 
>   #define MODULES_VADDR    (__START_KERNEL_map + KERNEL_IMAGE_SIZE)
> 
> So with KASLR, MODULES_VADDR gets pushed up from the traditional ffffffffa0000000
> up to ffffffffc0000000.
> 
> So I'm curious as to what you use in makedumpfile to determine whether
> CONFIG_RANDOMIZE_BASE has been configured?
> 
> Thanks,
>   Dave

Hey, sorry, I didn't notice that this was added upstream:

  commit 1303a27c9c32020a3b6ac89be270d2ab1f28be24
  Author: Baoquan He <bhe@redhat.com>
  Date:   Wed Sep 9 15:39:03 2015 -0700

    kexec: export KERNEL_IMAGE_SIZE to vmcoreinfo
    
With that in place, it will be an easy fix for the crash utility.

Thanks,
  Dave










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

Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled

[Pratyush Anand]

On Thursday 27 October 2016 08:55 PM, Dave Anderson wrote:
> As it turns out, the problem with the crash utility is that it has to
> calculate phys_base well before it even knows the kernel has been relocated
> by KASLR.  So when it sees the __START_KERNEL_map PT_LOAD segment, it mistakes
> it for the kernel modules' virtual address region and skips it.
>
> The kernel has this:
>
>   #if defined(CONFIG_RANDOMIZE_BASE)
>   #define KERNEL_IMAGE_SIZE       (1024 * 1024 * 1024)
>   #else
>   #define KERNEL_IMAGE_SIZE       (512 * 1024 * 1024)
>   #endif
>
> and then this:
>
>   #define MODULES_VADDR    (__START_KERNEL_map + KERNEL_IMAGE_SIZE)
>
> So with KASLR, MODULES_VADDR gets pushed up from the traditional ffffffffa0000000
> up to ffffffffc0000000.
>
> So I'm curious as to what you use in makedumpfile to determine whether
> CONFIG_RANDOMIZE_BASE has been configured?

So far we are trying to avoid to know that in makedumpfile. makedumpfile 
needed to know MODULES_VADDR, VMALLOC_START etc only to know that 
whether a VA to PA translation can be done using direct mapping or to be 
done by reading corresponding page table entry.

Now, we do VA to PA for all VAs using page table entry only.

https://github.com/pratyushanand/makedumpfile/blob/x86_devel/arch/x86_64.c#L186

~Pratyush

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

Re: [PATCH Makedumpfile 0/4] x86_64: Fix page_offset for randomized base enabled

[Dave Young]

On 10/27/16 at 11:41am, Dave Anderson wrote:
> 
> 
> ----- Original Message -----
> > 
> > 
> > ----- Original Message -----
> > 
> > >   
> > > That being said, my recent 4.8 and 4.9 KASLR testing has been on live
> > > systems and compressed kdumps, so the old tried-and-true manner of
> > > calculating the phys_base from the ELF PT_LOAD segments apparently
> > > no longer works with KASLR.
> > > 
> > > It would be so much more helpful if the VMCOREINFO data in the ELF
> > > header stored the actual phys_base value instead of its symbol value:
> > > 
> > >   crash> help -D
> > >   ...
> > >   SYMBOL(phys_base)=ffffffffa740b010
> > >   ...
> > > 
> > > which is completely useless unless the phys_base value is known.
> > > 
> > > Anyway, can you send me the makedumpfile code that calculates the
> > > phys_base value?
> > > 
> > > Dave
> > 
> > As it turns out, the problem with the crash utility is that it has to
> > calculate phys_base well before it even knows the kernel has been relocated
> > by KASLR.  So when it sees the __START_KERNEL_map PT_LOAD segment, it
> > mistakes
> > it for the kernel modules' virtual address region and skips it.
> > 
> > The kernel has this:
> > 
> >   #if defined(CONFIG_RANDOMIZE_BASE)
> >   #define KERNEL_IMAGE_SIZE       (1024 * 1024 * 1024)
> >   #else
> >   #define KERNEL_IMAGE_SIZE       (512 * 1024 * 1024)
> >   #endif
> > 
> > and then this:
> > 
> >   #define MODULES_VADDR    (__START_KERNEL_map + KERNEL_IMAGE_SIZE)
> > 
> > So with KASLR, MODULES_VADDR gets pushed up from the traditional ffffffffa0000000
> > up to ffffffffc0000000.
> > 
> > So I'm curious as to what you use in makedumpfile to determine whether
> > CONFIG_RANDOMIZE_BASE has been configured?
> > 
> > Thanks,
> >   Dave
> 
> Hey, sorry, I didn't notice that this was added upstream:
> 
>   commit 1303a27c9c32020a3b6ac89be270d2ab1f28be24
>   Author: Baoquan He <bhe@redhat.com>
>   Date:   Wed Sep 9 15:39:03 2015 -0700
> 
>     kexec: export KERNEL_IMAGE_SIZE to vmcoreinfo
>     
> With that in place, it will be an easy fix for the crash utility.

Dave, I confirmed your fix in crash git tree works, it also works for
the elf format vmcore, /proc/vmcore and makedumpfile -E created vmcore.

Thanks for the quick fix..

> 
> Thanks,
>   Dave
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

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