[v19,10/13] arm64: kdump: add VMCOREINFO's for user-space coredump tools

Commit Message

Geoff Levand June 16, 2016, 11:48 p.m. UTC

From: AKASHI Takahiro <[e-mail]>

For the current crash utility, we need to know, at least,
  - kimage_voffset
  - PHYS_OFFSET
to handle the contents of core dump file (/proc/vmcore) correctly due to
the introduction of KASLR (CONFIG_RANDOMIZE_BASE) in v4.6.
This patch puts them as VMCOREINFO's into the file.

  - VA_BITS
is also added for makedumpfile command.
More VMCOREINFO's may be added later.

Signed-off-by: AKASHI Takahiro <[e-mail]>
---
 arch/arm64/kernel/machine_kexec.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

Comments

Pratyush Anand June 20, 2016, 5:32 a.m. UTC | #1

+Atsushi

Hi Takahiro,

On 16/06/2016:11:48:28 PM, Geoff Levand wrote:
> From: AKASHI Takahiro <[e-mail]>
> 
> For the current crash utility, we need to know, at least,
>   - kimage_voffset
>   - PHYS_OFFSET
> to handle the contents of core dump file (/proc/vmcore) correctly due to
> the introduction of KASLR (CONFIG_RANDOMIZE_BASE) in v4.6.
> This patch puts them as VMCOREINFO's into the file.
> 
>   - VA_BITS
> is also added for makedumpfile command.

Thanks for adding them. They are quite helpful for makedumpfile as well.

> More VMCOREINFO's may be added later.

Yes, we will need to pass VMCOREINFO_SYMBOL(_text) and VMCOREINFO_SYMBOL(_end)
in order to work with makedumpfile.

I already have makedumpfile patches [1]  which uses _text and _end, but not
sending them to makedumpfile upstream, until you will be agreeing to take [2] in
future. Please let me know your opinion about it. If it would be acceptable then
I may send aarch64 makedumpfile improvements to upstream.

[1] https://github.com/pratyushanand/makedumpfile/commit/d9590fec049976b8fee0d6b4e66e6f3e99ff1113
[2] https://github.com/pratyushanand/linux/commit/1d94df20c575c725910c9c29a129b9f14e7e900b

~Pratyush

> 
> Signed-off-by: AKASHI Takahiro <[e-mail]>
> ---
>  arch/arm64/kernel/machine_kexec.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
> index f270967..57a30fb 100644
> --- a/arch/arm64/kernel/machine_kexec.c
> +++ b/arch/arm64/kernel/machine_kexec.c
> @@ -18,6 +18,7 @@
>  
>  #include <asm/cacheflush.h>
>  #include <asm/cpu_ops.h>
> +#include <asm/memory.h>
>  #include <asm/mmu_context.h>
>  
>  #include "cpu-reset.h"
> @@ -278,3 +279,13 @@ void machine_crash_shutdown(struct pt_regs *regs)
>  
>  	pr_info("Starting crashdump kernel...\n");
>  }
> +
> +void arch_crash_save_vmcoreinfo(void)
> +{
> +	VMCOREINFO_NUMBER(VA_BITS);
> +	/* Please note VMCOREINFO_NUMBER() uses "%d", not "%x" */
> +	vmcoreinfo_append_str("NUMBER(kimage_voffset)=0x%llx\n",
> +						kimage_voffset);
> +	vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%llx\n",
> +						PHYS_OFFSET);
> +}
> -- 
> 2.5.0
> 
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> [e-mail]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

AKASHI Takahiro June 22, 2016, 5:59 a.m. UTC | #2

On Mon, Jun 20, 2016 at 11:02:22AM +0530, Pratyush Anand wrote:
> +Atsushi
> 
> Hi Takahiro,
> 
> On 16/06/2016:11:48:28 PM, Geoff Levand wrote:
> > From: AKASHI Takahiro <[e-mail]>
> > 
> > For the current crash utility, we need to know, at least,
> >   - kimage_voffset
> >   - PHYS_OFFSET
> > to handle the contents of core dump file (/proc/vmcore) correctly due to
> > the introduction of KASLR (CONFIG_RANDOMIZE_BASE) in v4.6.
> > This patch puts them as VMCOREINFO's into the file.
> > 
> >   - VA_BITS
> > is also added for makedumpfile command.
> 
> Thanks for adding them. They are quite helpful for makedumpfile as well.
> 
> > More VMCOREINFO's may be added later.
> 
> Yes, we will need to pass VMCOREINFO_SYMBOL(_text) and VMCOREINFO_SYMBOL(_end)
> in order to work with makedumpfile.

I know that adding those symbols is the easiest way, but
theoretically, if we know the physical address of "swapper_pg_dir",
instead of its virtual address, we can access all the memory pointed to
by any kernel virtual address.
How do you rationalize that we need to know "_text" and "_end"?

Thanks,
-Takahiro AKASHI

> I already have makedumpfile patches [1]  which uses _text and _end, but not
> sending them to makedumpfile upstream, until you will be agreeing to take [2] in
> future. Please let me know your opinion about it. If it would be acceptable then
> I may send aarch64 makedumpfile improvements to upstream.
> 
> [1] https://github.com/pratyushanand/makedumpfile/commit/d9590fec049976b8fee0d6b4e66e6f3e99ff1113
> [2] https://github.com/pratyushanand/linux/commit/1d94df20c575c725910c9c29a129b9f14e7e900b
> 
> ~Pratyush
> 
> > 
> > Signed-off-by: AKASHI Takahiro <[e-mail]>
> > ---
> >  arch/arm64/kernel/machine_kexec.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
> > index f270967..57a30fb 100644
> > --- a/arch/arm64/kernel/machine_kexec.c
> > +++ b/arch/arm64/kernel/machine_kexec.c
> > @@ -18,6 +18,7 @@
> >  
> >  #include <asm/cacheflush.h>
> >  #include <asm/cpu_ops.h>
> > +#include <asm/memory.h>
> >  #include <asm/mmu_context.h>
> >  
> >  #include "cpu-reset.h"
> > @@ -278,3 +279,13 @@ void machine_crash_shutdown(struct pt_regs *regs)
> >  
> >  	pr_info("Starting crashdump kernel...\n");
> >  }
> > +
> > +void arch_crash_save_vmcoreinfo(void)
> > +{
> > +	VMCOREINFO_NUMBER(VA_BITS);
> > +	/* Please note VMCOREINFO_NUMBER() uses "%d", not "%x" */
> > +	vmcoreinfo_append_str("NUMBER(kimage_voffset)=0x%llx\n",
> > +						kimage_voffset);
> > +	vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%llx\n",
> > +						PHYS_OFFSET);
> > +}
> > -- 
> > 2.5.0
> > 
> > 
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > [e-mail]
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Pratyush Anand June 23, 2016, 7:14 a.m. UTC | #3

Hi Takahiro,

Thanks for your reply.

On 22/06/2016:02:59:41 PM, AKASHI Takahiro wrote:
> On Mon, Jun 20, 2016 at 11:02:22AM +0530, Pratyush Anand wrote:
> > +Atsushi
> > 
> > Hi Takahiro,
> > 
> > On 16/06/2016:11:48:28 PM, Geoff Levand wrote:
> > > From: AKASHI Takahiro <[e-mail]>
> > > 
> > > For the current crash utility, we need to know, at least,
> > >   - kimage_voffset
> > >   - PHYS_OFFSET
> > > to handle the contents of core dump file (/proc/vmcore) correctly due to
> > > the introduction of KASLR (CONFIG_RANDOMIZE_BASE) in v4.6.
> > > This patch puts them as VMCOREINFO's into the file.
> > > 
> > >   - VA_BITS
> > > is also added for makedumpfile command.
> > 
> > Thanks for adding them. They are quite helpful for makedumpfile as well.
> > 
> > > More VMCOREINFO's may be added later.
> > 
> > Yes, we will need to pass VMCOREINFO_SYMBOL(_text) and VMCOREINFO_SYMBOL(_end)
> > in order to work with makedumpfile.
> 
> I know that adding those symbols is the easiest way, but
> theoretically, if we know the physical address of "swapper_pg_dir",

But, we know only it's virtual address. 

> instead of its virtual address, we can access all the memory pointed to
> by any kernel virtual address.
> How do you rationalize that we need to know "_text" and "_end"?

Well, we need some mechanism so that we can decide if an address can be
translated using linear mapping of virt_to_phys(). 

Alternatively, probably we can do like this:
-- Translate all address between "SYMBOL(swapper_pg_dir)"  and "SYMBOL(swapper_pg_dir)
 + SWAPPER_DIR_SIZE" using virt_to_phys() and now we can read values from
 dumpfile using that physical address. This way we can get PGD/PMD/PUD values.
-- PTE values may lie out side this range, however that address should still be
linearly translatable. We can use virt_to_phys() macro from them as well.

In summary, we can translate address of PGD/PMD/PUD/PTE using virt_to_phys()
and rest all can be translated using page table entries.

~Pratyush

AKASHI Takahiro June 23, 2016, 8:42 a.m. UTC | #4

On Thu, Jun 23, 2016 at 12:44:12PM +0530, Pratyush Anand wrote:
> Hi Takahiro,
> 
> Thanks for your reply.
> 
> On 22/06/2016:02:59:41 PM, AKASHI Takahiro wrote:
> > On Mon, Jun 20, 2016 at 11:02:22AM +0530, Pratyush Anand wrote:
> > > +Atsushi
> > > 
> > > Hi Takahiro,
> > > 
> > > On 16/06/2016:11:48:28 PM, Geoff Levand wrote:
> > > > From: AKASHI Takahiro <[e-mail]>
> > > > 
> > > > For the current crash utility, we need to know, at least,
> > > >   - kimage_voffset
> > > >   - PHYS_OFFSET
> > > > to handle the contents of core dump file (/proc/vmcore) correctly due to
> > > > the introduction of KASLR (CONFIG_RANDOMIZE_BASE) in v4.6.
> > > > This patch puts them as VMCOREINFO's into the file.
> > > > 
> > > >   - VA_BITS
> > > > is also added for makedumpfile command.
> > > 
> > > Thanks for adding them. They are quite helpful for makedumpfile as well.
> > > 
> > > > More VMCOREINFO's may be added later.
> > > 
> > > Yes, we will need to pass VMCOREINFO_SYMBOL(_text) and VMCOREINFO_SYMBOL(_end)
> > > in order to work with makedumpfile.
> > 
> > I know that adding those symbols is the easiest way, but
> > theoretically, if we know the physical address of "swapper_pg_dir",
> 
> But, we know only it's virtual address. 

What I meant here is that, if we know the physical address of "swapper_pg_dir",
we don't have to know neither of "_text", "_end", "kimage_voffset" nor
"PHYS_OFFSET".
I just wanted to ask you whether you thought of this possibility.
> 
> > instead of its virtual address, we can access all the memory pointed to
> > by any kernel virtual address.
> > How do you rationalize that we need to know "_text" and "_end"?
> 
> Well, we need some mechanism so that we can decide if an address can be
> translated using linear mapping of virt_to_phys(). 

All the entries in MMU tables are based on "physical" addresses,
and so we don't care whether a given address is in linear mapping or not
in walking through MMU.
See what I mean?

Thanks,
-Takahiro AKASHI

> Alternatively, probably we can do like this:
> -- Translate all address between "SYMBOL(swapper_pg_dir)"  and "SYMBOL(swapper_pg_dir)
>  + SWAPPER_DIR_SIZE" using virt_to_phys() and now we can read values from
>  dumpfile using that physical address. This way we can get PGD/PMD/PUD values.
> -- PTE values may lie out side this range, however that address should still be
> linearly translatable. We can use virt_to_phys() macro from them as well.
> 
> In summary, we can translate address of PGD/PMD/PUD/PTE using virt_to_phys()
> and rest all can be translated using page table entries.
> 
> ~Pratyush

Pratyush Anand June 23, 2016, 3:46 p.m. UTC | #5

On 23/06/2016:05:42:28 PM, AKASHI Takahiro wrote:
> On Thu, Jun 23, 2016 at 12:44:12PM +0530, Pratyush Anand wrote:
> > Hi Takahiro,
> > 
> > Thanks for your reply.
> > 
> > On 22/06/2016:02:59:41 PM, AKASHI Takahiro wrote:
> > > On Mon, Jun 20, 2016 at 11:02:22AM +0530, Pratyush Anand wrote:
> > > > +Atsushi
> > > > 
> > > > Hi Takahiro,
> > > > 
> > > > On 16/06/2016:11:48:28 PM, Geoff Levand wrote:
> > > > > From: AKASHI Takahiro <[e-mail]>
> > > > > 
> > > > > For the current crash utility, we need to know, at least,
> > > > >   - kimage_voffset
> > > > >   - PHYS_OFFSET
> > > > > to handle the contents of core dump file (/proc/vmcore) correctly due to
> > > > > the introduction of KASLR (CONFIG_RANDOMIZE_BASE) in v4.6.
> > > > > This patch puts them as VMCOREINFO's into the file.
> > > > > 
> > > > >   - VA_BITS
> > > > > is also added for makedumpfile command.
> > > > 
> > > > Thanks for adding them. They are quite helpful for makedumpfile as well.
> > > > 
> > > > > More VMCOREINFO's may be added later.
> > > > 
> > > > Yes, we will need to pass VMCOREINFO_SYMBOL(_text) and VMCOREINFO_SYMBOL(_end)
> > > > in order to work with makedumpfile.
> > > 
> > > I know that adding those symbols is the easiest way, but
> > > theoretically, if we know the physical address of "swapper_pg_dir",
> > 
> > But, we know only it's virtual address. 
> 
> What I meant here is that, if we know the physical address of "swapper_pg_dir",
> we don't have to know neither of "_text", "_end", "kimage_voffset" nor
> "PHYS_OFFSET".
> I just wanted to ask you whether you thought of this possibility.

OK, Let me clarify the needs from makedumpfile perspective. Atsushi can correct
me if I am wrong:

- As a minimal we need some way of reading page table entries. Currently vmcore
  has only virtual address of swapper_pg_dir, but if you can provide
  __pa(swapper_pg_dir) in vmcore, then we do not need either "_text", "_end" or
  "kimage_voffset". 
- However, "PHYS_OFFSET" might still be needed. makedumpfile core code needs to
  know phys_base. Currently we find it from the PT_LOAD segments. We treat the
  lowest start of segment's LMAs as the physical base. I am not sure, if that is
  still true with latest KASAN changes.
- Further, if you do not provide "_text" and "_end", then we will have to translate
  each address with complex page table read process, which would slow
  makedumpfile execution significantly.

Now, please let us know that what will be the kernel strategy, so that I can
re-organise makedumpfile accordingly.

> > 
> > > instead of its virtual address, we can access all the memory pointed to
> > > by any kernel virtual address.
> > > How do you rationalize that we need to know "_text" and "_end"?
> > 
> > Well, we need some mechanism so that we can decide if an address can be
> > translated using linear mapping of virt_to_phys(). 
> 
> All the entries in MMU tables are based on "physical" addresses,
> and so we don't care whether a given address is in linear mapping or not
> in walking through MMU.
> See what I mean?

Yes, yes, I thought, we have only virtual swapper_pg_dir, so I was looking for a
way to translate *atleast* that into physical.

Thanks for your input. Those are helpful.

~Pratyush

> 
> Thanks,
> -Takahiro AKASHI
> 
> > Alternatively, probably we can do like this:
> > -- Translate all address between "SYMBOL(swapper_pg_dir)"  and "SYMBOL(swapper_pg_dir)
> >  + SWAPPER_DIR_SIZE" using virt_to_phys() and now we can read values from
> >  dumpfile using that physical address. This way we can get PGD/PMD/PUD values.
> > -- PTE values may lie out side this range, however that address should still be
> > linearly translatable. We can use virt_to_phys() macro from them as well.
> > 
> > In summary, we can translate address of PGD/PMD/PUD/PTE using virt_to_phys()
> > and rest all can be translated using page table entries.
> > 
> > ~Pratyush

AKASHI Takahiro June 30, 2016, 12:44 a.m. UTC | #6

Pratyush,

On Thu, Jun 23, 2016 at 09:16:24PM +0530, Pratyush Anand wrote:
> On 23/06/2016:05:42:28 PM, AKASHI Takahiro wrote:
> > On Thu, Jun 23, 2016 at 12:44:12PM +0530, Pratyush Anand wrote:
> > > Hi Takahiro,
> > > 
> > > Thanks for your reply.
> > > 
> > > On 22/06/2016:02:59:41 PM, AKASHI Takahiro wrote:
> > > > On Mon, Jun 20, 2016 at 11:02:22AM +0530, Pratyush Anand wrote:
> > > > > +Atsushi
> > > > > 
> > > > > Hi Takahiro,
> > > > > 
> > > > > On 16/06/2016:11:48:28 PM, Geoff Levand wrote:
> > > > > > From: AKASHI Takahiro <[e-mail]>
> > > > > > 
> > > > > > For the current crash utility, we need to know, at least,
> > > > > >   - kimage_voffset
> > > > > >   - PHYS_OFFSET
> > > > > > to handle the contents of core dump file (/proc/vmcore) correctly due to
> > > > > > the introduction of KASLR (CONFIG_RANDOMIZE_BASE) in v4.6.
> > > > > > This patch puts them as VMCOREINFO's into the file.
> > > > > > 
> > > > > >   - VA_BITS
> > > > > > is also added for makedumpfile command.
> > > > > 
> > > > > Thanks for adding them. They are quite helpful for makedumpfile as well.
> > > > > 
> > > > > > More VMCOREINFO's may be added later.
> > > > > 
> > > > > Yes, we will need to pass VMCOREINFO_SYMBOL(_text) and VMCOREINFO_SYMBOL(_end)
> > > > > in order to work with makedumpfile.
> > > > 
> > > > I know that adding those symbols is the easiest way, but
> > > > theoretically, if we know the physical address of "swapper_pg_dir",
> > > 
> > > But, we know only it's virtual address. 
> > 
> > What I meant here is that, if we know the physical address of "swapper_pg_dir",
> > we don't have to know neither of "_text", "_end", "kimage_voffset" nor
> > "PHYS_OFFSET".
> > I just wanted to ask you whether you thought of this possibility.
> 
> OK, Let me clarify the needs from makedumpfile perspective. Atsushi can correct
> me if I am wrong:
> 
> - As a minimal we need some way of reading page table entries. Currently vmcore
>   has only virtual address of swapper_pg_dir, but if you can provide
>   __pa(swapper_pg_dir) in vmcore, then we do not need either "_text", "_end" or
>   "kimage_voffset". 
> - However, "PHYS_OFFSET" might still be needed. makedumpfile core code needs to
>   know phys_base. Currently we find it from the PT_LOAD segments. We treat the
>   lowest start of segment's LMAs as the physical base. I am not sure, if that is
>   still true with latest KASAN changes.

PHYS_OFFSET is now there in patch 10/13.

> - Further, if you do not provide "_text" and "_end", then we will have to translate
>   each address with complex page table read process, which would slow
>   makedumpfile execution significantly.

I believe that this is the only reason that you want both symbols
though I don't know how much performance penalty it may cause.

> Now, please let us know that what will be the kernel strategy, so that I can
> re-organise makedumpfile accordingly.

Given that I'm not a user nor author of makedumpfile command for arm64,
as we discussed locally before, I'm now convinced that you'd better post
your own kernel patch based on your requirements as you like.

Thanks,
-Takahiro AKASHI

> > > 
> > > > instead of its virtual address, we can access all the memory pointed to
> > > > by any kernel virtual address.
> > > > How do you rationalize that we need to know "_text" and "_end"?
> > > 
> > > Well, we need some mechanism so that we can decide if an address can be
> > > translated using linear mapping of virt_to_phys(). 
> > 
> > All the entries in MMU tables are based on "physical" addresses,
> > and so we don't care whether a given address is in linear mapping or not
> > in walking through MMU.
> > See what I mean?
> 
> Yes, yes, I thought, we have only virtual swapper_pg_dir, so I was looking for a
> way to translate *atleast* that into physical.
> 
> Thanks for your input. Those are helpful.
> 
> ~Pratyush
> 
> > 
> > Thanks,
> > -Takahiro AKASHI
> > 
> > > Alternatively, probably we can do like this:
> > > -- Translate all address between "SYMBOL(swapper_pg_dir)"  and "SYMBOL(swapper_pg_dir)
> > >  + SWAPPER_DIR_SIZE" using virt_to_phys() and now we can read values from
> > >  dumpfile using that physical address. This way we can get PGD/PMD/PUD values.
> > > -- PTE values may lie out side this range, however that address should still be
> > > linearly translatable. We can use virt_to_phys() macro from them as well.
> > > 
> > > In summary, we can translate address of PGD/PMD/PUD/PTE using virt_to_phys()
> > > and rest all can be translated using page table entries.
> > > 
> > > ~Pratyush

Patch

diff --git a/arch/arm64/kernel/machine_kexec.c b/arch/arm64/kernel/machine_kexec.c
index f270967..57a30fb 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -18,6 +18,7 @@ 
 
 #include <asm/cacheflush.h>
 #include <asm/cpu_ops.h>
+#include <asm/memory.h>
 #include <asm/mmu_context.h>
 
 #include "cpu-reset.h"
@@ -278,3 +279,13 @@  void machine_crash_shutdown(struct pt_regs *regs)
 
 	pr_info("Starting crashdump kernel...\n");
 }
+
+void arch_crash_save_vmcoreinfo(void)
+{
+	VMCOREINFO_NUMBER(VA_BITS);
+	/* Please note VMCOREINFO_NUMBER() uses "%d", not "%x" */
+	vmcoreinfo_append_str("NUMBER(kimage_voffset)=0x%llx\n",
+						kimage_voffset);
+	vmcoreinfo_append_str("NUMBER(PHYS_OFFSET)=0x%llx\n",
+						PHYS_OFFSET);
+}