Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[Atsushi Kumagai]

Hello,

>On 27/05/2016:01:03:56 PM, AKASHI Takahiro wrote:
>> On Thu, May 26, 2016 at 03:09:55PM +0530, Pratyush Anand wrote:
>> > On 26/05/2016:05:13:30 PM, AKASHI Takahiro wrote:
>> > > On Wed, May 25, 2016 at 10:28:10AM -0400, Dave Anderson wrote:
>> >
>> > [...]
>> >
>> > > > > (This is the reason that I don't think we need a VMCOREINFO for
>> > > > > CONFIG_RANDOMIZE_BASE.)
>> > > >
>> > > > Well, as long as there's a way to avoid that unnecessary/confusing
>> > > > warning message for non-KASLR new-vmemmap kernels.
>> > > >
>> > > > I also wonder whether makedumpfile could use it?
>> > >
>> > > -> Pratyush?
>> >
>> > Since  second kernel's initrd cannot include a large file like VMLINUX, so
>> > makedumpfile should also work without passing '-x vmlinux'.  Therefore,
>> > makedumpfile will need some minimal symbol's values to be passed in vmcore.
>>
>> I understand.
>> (but I wonder why makedumpfile doesn't utilize System.map nor .config.)
>
>So far makedumpfile has been designed to work only with vmcore as input in it's
>minimal form (specially in second kernel).
>+Atsushi & makedumpfile list: He will have better idea about it.

I'm not the designer, but I think it was designed to get robustness.
If /proc/vmcore itself provides the stuffs for analysis, it prevents the 
inconsistency between passed symbol list(like System.map) and actual kernel
memory image.

Additionally, makedumpfile requires not only symbol address list but struct
member's offset, struct size and enum number. So vmcoreinfo is needed anyway.

>Moreover, there are few variables, whose values are needed in order to 
>translate
>phys to virt and vice versa. So, passing their symbol address would not be of
>much help. For example, we need to know value of kimage_voffset for __pa(), and
>so symbol address of kimage_voffset will not help.
>
>>
>> > IIUC, then you need to pass CONFIG_RANDOMIZE_BASE in order to calculate
>> > PHYS_OFFSET. If yes, then why not to pass PHYS_OFFSET itself into vmcore.
>>
>> No, as I said in the discussions, I don't think that we need
>> CONFIG_RANDOMIZE_BASE *if* we can read a kernel symbol's value
>> from /proc/vmcore.
>
>What I understand that, we can read only those symbols/variables from vmcore
>which have been embedded using VMCOREINFO_ macros (if we do not pass
>vmlinux, like in second kernel). Atsushi, please correct me if I am wrong.

That's right.

>>
>> > Following numbers in vmcore [1] is helping me out in implementing __pa() 
>> > and
>> > __va() for all page table sizes and levels.
>> >
>> > VMCOREINFO_NUMBER(pgtable_levels);
>> > VMCOREINFO_NUMBER(va_bits);
>> > VMCOREINFO_NUMBER(page_shift);
>>
>> Since We already have VMCOREINFO(PAGESIZE), we won't nedd page_shift.
>
>Yes, agreed.
>
>> As well, pgtable_levels can be determined by va_bits and PAGESIZE.
>> See arch/arm64/Kconfig.
>
>Yes, agreed.
>
>>
>> > VMCOREINFO_NUMBER(phys_offset);
>> > VMCOREINFO_NUMBER(config_kasan);
>>
>> Let me ask some questions.
>> * What kind of data in vmcore and how does makedumpfile access
>>   without vmlinux nor System.map?
>
>Well, I do not have the deep idea, again Atsushi can help here.
>
>makedumpfile mainly compresses vmcore (ram image of panicked kernel),
>additionally it also excludes unnecessary pages for analysis. It will need
>symbol information to exclude unnecessary pages, where vmlinux is needed 
>mainly.
>So, normally we do not perform erase(exclude) functionality in second kernel. 
>It
>is being performed latter, on a compressed dumpfile.

Yes, basically the data in vmcore are used to exclude unnecessary pages.
Most data are required to get the members of struct page to distinguish
what kind of page it is.


Thanks,
Astushi Kumagai

>> * Why do you need CONFIG_KASAN?
>
>KASAN_SHADOW_SIZE is dependent on CONFIG_KASAN.
>MODULES_VADDR is dependent on KASAN_SHADOW_SIZE.
>
>We need MODULES_VADDR,VMALLOC_START,VMEMMAP_START and their END addresses in
>order to define whether a virtual to physical translation can be obtained using
>linear mapping or need to read from page table instead.
>
>Thanks for the questions and inputs.  Those are helpful. :-)
>~Pratyush
>>
>> Thanks,
>> -Takahiro AKASHI
>>
>> > VMCOREINFO_NUMBER(kimage_voffset);
>> >
>> > ~Pratyush
>> >
>> > [1]
>> >
>https://github.com/pratyushanand/linux/blob/7011e478aae3e568cc8dca15b6c128fe728416f7/arch/arm64/kernel/machine_kexec
>.c#L275
>> >
>> > --
>> > Crash-utility mailing list
>> > Crash-utility@redhat.com
>> > https://www.redhat.com/mailman/listinfo/crash-utility
>>
>> --
>> Thanks,
>> -Takahiro AKASHI
>>
>> --
>> Crash-utility mailing list
>> Crash-utility@redhat.com
>> https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[Pratyush Anand]

On 27/05/2016:03:43:33 PM, AKASHI Takahiro wrote:
> On Fri, May 27, 2016 at 10:37:38AM +0530, Pratyush Anand wrote:
> > On 27/05/2016:01:03:56 PM, AKASHI Takahiro wrote:
> > > On Thu, May 26, 2016 at 03:09:55PM +0530, Pratyush Anand wrote:
> > > > On 26/05/2016:05:13:30 PM, AKASHI Takahiro wrote:
> > > > > On Wed, May 25, 2016 at 10:28:10AM -0400, Dave Anderson wrote:
> > > > 
> > > > [...]
> > > > 
> > > > > > > (This is the reason that I don't think we need a VMCOREINFO for
> > > > > > > CONFIG_RANDOMIZE_BASE.)
> > > > > > 
> > > > > > Well, as long as there's a way to avoid that unnecessary/confusing
> > > > > > warning message for non-KASLR new-vmemmap kernels.
> > > > > > 
> > > > > > I also wonder whether makedumpfile could use it?
> > > > > 
> > > > > -> Pratyush?
> > > > 
> > > > Since  second kernel's initrd cannot include a large file like VMLINUX, 
> > > > so
> > > > makedumpfile should also work without passing '-x vmlinux'.  Therefore,
> > > > makedumpfile will need some minimal symbol's values to be passed in 
> > > > vmcore.
> > > 
> > > I understand.
> > > (but I wonder why makedumpfile doesn't utilize System.map nor .config.)
> > 
> > So far makedumpfile has been designed to work only with vmcore as input in 
> > it's
> > minimal form (specially in second kernel).
> > +Atsushi & makedumpfile list: He will have better idea about it.
> > 
> > Moreover, there are few variables, whose values are needed in order to 
> > translate
> > phys to virt and vice versa. So, passing their symbol address would not be 
> > of
> > much help. For example, we need to know value of kimage_voffset for __pa(), 
> > and
> > so symbol address of kimage_voffset will not help.
> 
> I do agree to adding any vmcoreinfo *if* it is really needed,
> and so I'm asking why you need it.
> 
> What I'm thinking now is that I would add a minimal set of vmcoreinfo
> which are necessary for crash util to work (for /proc/vmcore, not a live
> system) and then, if you want to add anything else, you can post your
> own patch.
> 
> Make sense?

Yes, No issue.
In fact, I do not have any plan to send arm64 makedulpfile enhancement either
until kernel support is upstreamed.

> 
> But I think ...
> If we would eventually add, say, "NUMBER(va_bits)", makedumpfile() will
> use it, but crash util doen't. Looks a bit odd.

> -> Dave, do you have any opinion here?
> 
> > > 
> > > > IIUC, then you need to pass CONFIG_RANDOMIZE_BASE in order to calculate
> > > > PHYS_OFFSET. If yes, then why not to pass PHYS_OFFSET itself into 
> > > > vmcore.
> > > 
> > > No, as I said in the discussions, I don't think that we need
> > > CONFIG_RANDOMIZE_BASE *if* we can read a kernel symbol's value
> > > from /proc/vmcore.
> > 
> > What I understand that, we can read only those symbols/variables from vmcore
> > which have been embedded using VMCOREINFO_ macros (if we do not pass
> > vmlinux, like in second kernel). Atsushi, please correct me if I am wrong.
> > 
> > > 
> > > > Following numbers in vmcore [1] is helping me out in implementing 
> > > > __pa() and
> > > > __va() for all page table sizes and levels.
> > > > 
> > > > VMCOREINFO_NUMBER(pgtable_levels);
> > > > VMCOREINFO_NUMBER(va_bits);
> > > > VMCOREINFO_NUMBER(page_shift);
> > > 
> > > Since We already have VMCOREINFO(PAGESIZE), we won't nedd page_shift.
> > 
> > Yes, agreed.
> > 
> > > As well, pgtable_levels can be determined by va_bits and PAGESIZE.
> > > See arch/arm64/Kconfig.
> > 
> > Yes, agreed.
> > 
> > > 
> > > > VMCOREINFO_NUMBER(phys_offset);
> > > > VMCOREINFO_NUMBER(config_kasan);
> > > 
> > > Let me ask some questions.
> > > * What kind of data in vmcore and how does makedumpfile access
> > >   without vmlinux nor System.map?
> > 
> > Well, I do not have the deep idea, again Atsushi can help here.
> > 
> > makedumpfile mainly compresses vmcore (ram image of panicked kernel),
> > additionally it also excludes unnecessary pages for analysis. It will need
> > symbol information to exclude unnecessary pages, where vmlinux is needed 
> > mainly.
> > So, normally we do not perform erase(exclude) functionality in second 
> > kernel. It
> > is being performed latter, on a compressed dumpfile.
> 
> Well, I don't look into the makedumpfile code in details, it only accesses
> MMU tables and struct page data. So you need a few *well-known* symbols'
> values in vmcore.
> 
> > > * Why do you need CONFIG_KASAN?
> > 
> > KASAN_SHADOW_SIZE is dependent on CONFIG_KASAN.
> > MODULES_VADDR is dependent on KASAN_SHADOW_SIZE.
> > 
> > We need MODULES_VADDR,VMALLOC_START,VMEMMAP_START and their END addresses in
> > order to define whether a virtual to physical translation can be obtained 
> > using
> > linear mapping or need to read from page table instead.
> 
> I guess that we can check for this simply like:
> vaddr >= PAGE_OFFSET || ("_text" <= vaddr < "_end")
> (Again, *if* we can access kernel symbols' values.)

Unfortunately, We have _stext in vmcore but we do not have _text and _end.

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[AKASHI Takahiro]

On Fri, May 27, 2016 at 10:37:38AM +0530, Pratyush Anand wrote:
> On 27/05/2016:01:03:56 PM, AKASHI Takahiro wrote:
> > On Thu, May 26, 2016 at 03:09:55PM +0530, Pratyush Anand wrote:
> > > On 26/05/2016:05:13:30 PM, AKASHI Takahiro wrote:
> > > > On Wed, May 25, 2016 at 10:28:10AM -0400, Dave Anderson wrote:
> > > 
> > > [...]
> > > 
> > > > > > (This is the reason that I don't think we need a VMCOREINFO for
> > > > > > CONFIG_RANDOMIZE_BASE.)
> > > > > 
> > > > > Well, as long as there's a way to avoid that unnecessary/confusing
> > > > > warning message for non-KASLR new-vmemmap kernels.
> > > > > 
> > > > > I also wonder whether makedumpfile could use it?
> > > > 
> > > > -> Pratyush?
> > > 
> > > Since  second kernel's initrd cannot include a large file like VMLINUX, so
> > > makedumpfile should also work without passing '-x vmlinux'.  Therefore,
> > > makedumpfile will need some minimal symbol's values to be passed in 
> > > vmcore.
> > 
> > I understand.
> > (but I wonder why makedumpfile doesn't utilize System.map nor .config.)
> 
> So far makedumpfile has been designed to work only with vmcore as input in 
> it's
> minimal form (specially in second kernel).
> +Atsushi & makedumpfile list: He will have better idea about it.
> 
> Moreover, there are few variables, whose values are needed in order to 
> translate
> phys to virt and vice versa. So, passing their symbol address would not be of
> much help. For example, we need to know value of kimage_voffset for __pa(), 
> and
> so symbol address of kimage_voffset will not help.

I do agree to adding any vmcoreinfo *if* it is really needed,
and so I'm asking why you need it.

What I'm thinking now is that I would add a minimal set of vmcoreinfo
which are necessary for crash util to work (for /proc/vmcore, not a live
system) and then, if you want to add anything else, you can post your
own patch.

Make sense?

But I think ...
If we would eventually add, say, "NUMBER(va_bits)", makedumpfile() will
use it, but crash util doen't. Looks a bit odd.

-> Dave, do you have any opinion here?

> > 
> > > IIUC, then you need to pass CONFIG_RANDOMIZE_BASE in order to calculate
> > > PHYS_OFFSET. If yes, then why not to pass PHYS_OFFSET itself into vmcore.
> > 
> > No, as I said in the discussions, I don't think that we need
> > CONFIG_RANDOMIZE_BASE *if* we can read a kernel symbol's value
> > from /proc/vmcore.
> 
> What I understand that, we can read only those symbols/variables from vmcore
> which have been embedded using VMCOREINFO_ macros (if we do not pass
> vmlinux, like in second kernel). Atsushi, please correct me if I am wrong.
> 
> > 
> > > Following numbers in vmcore [1] is helping me out in implementing __pa() 
> > > and
> > > __va() for all page table sizes and levels.
> > > 
> > > VMCOREINFO_NUMBER(pgtable_levels);
> > > VMCOREINFO_NUMBER(va_bits);
> > > VMCOREINFO_NUMBER(page_shift);
> > 
> > Since We already have VMCOREINFO(PAGESIZE), we won't nedd page_shift.
> 
> Yes, agreed.
> 
> > As well, pgtable_levels can be determined by va_bits and PAGESIZE.
> > See arch/arm64/Kconfig.
> 
> Yes, agreed.
> 
> > 
> > > VMCOREINFO_NUMBER(phys_offset);
> > > VMCOREINFO_NUMBER(config_kasan);
> > 
> > Let me ask some questions.
> > * What kind of data in vmcore and how does makedumpfile access
> >   without vmlinux nor System.map?
> 
> Well, I do not have the deep idea, again Atsushi can help here.
> 
> makedumpfile mainly compresses vmcore (ram image of panicked kernel),
> additionally it also excludes unnecessary pages for analysis. It will need
> symbol information to exclude unnecessary pages, where vmlinux is needed 
> mainly.
> So, normally we do not perform erase(exclude) functionality in second kernel. 
> It
> is being performed latter, on a compressed dumpfile.

Well, I don't look into the makedumpfile code in details, it only accesses
MMU tables and struct page data. So you need a few *well-known* symbols'
values in vmcore.

> > * Why do you need CONFIG_KASAN?
> 
> KASAN_SHADOW_SIZE is dependent on CONFIG_KASAN.
> MODULES_VADDR is dependent on KASAN_SHADOW_SIZE.
> 
> We need MODULES_VADDR,VMALLOC_START,VMEMMAP_START and their END addresses in
> order to define whether a virtual to physical translation can be obtained 
> using
> linear mapping or need to read from page table instead.

I guess that we can check for this simply like:
vaddr >= PAGE_OFFSET || ("_text" <= vaddr < "_end")
(Again, *if* we can access kernel symbols' values.)

Thanks,
-Takahiro AKASHI

> Thanks for the questions and inputs.  Those are helpful. :-)
> ~Pratyush
> > 
> > Thanks,
> > -Takahiro AKASHI
> > 
> > > VMCOREINFO_NUMBER(kimage_voffset);
> > > 
> > > ~Pratyush
> > > 
> > > [1]
> > > https://github.com/pratyushanand/linux/blob/7011e478aae3e568cc8dca15b6c128fe728416f7/arch/arm64/kernel/machine_kexec.c#L275
> > > 
> > > --
> > > Crash-utility mailing list
> > > Crash-utility@redhat.com
> > > https://www.redhat.com/mailman/listinfo/crash-utility
> > 
> > -- 
> > Thanks,

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[AKASHI Takahiro]

On Fri, May 27, 2016 at 09:46:10AM +0530, Pratyush Anand wrote:
> On 27/05/2016:12:18:56 PM, AKASHI Takahiro wrote:
> > On Thu, May 26, 2016 at 01:27:08PM +0530, Pratyush Anand wrote:
> > > On 26/05/2016:04:04:08 PM, AKASHI Takahiro wrote:
> > > > Pratyush,
> > > > 
> > > > Just for debug purpose.
> > > > Please add the following line to *your* arch_crash_save_vmcoreinfo():
> > > > > vmcoreinfo_append_str("NUMBER(kimage_voffset)=%llx\n", 
> > > > > kimage_voffset);
> > > 
> > > Thanks for the pointer.
> > > 
> > > I did had VMCOREINFO_NUMBER(kimage_voffset) in 
> > > arch_crash_save_vmcoreinfo().
> > > 
> > > https://github.com/pratyushanand/linux/commit/7011e478aae3e568cc8dca15b6c128fe728416f7#diff-cdf29c3b9471b9d813afc107dd154acdR291
> > > 
> > > But, I noticed that in crash code you have "ms->kimage_voffset = 
> > > htol(string,
> > > QUIET, NULL);". So, the change you have suggested will work.
> > 
> > I know that. It is intentional.
> > 
> > > However, I think its preferable to use VMCOREINFO_NUMBER() macro instead.
> > > makedumpfile is able to calculate kimage_voffset correctly with that 
> > > without any
> > > issue.
> > 
> > I think that VMCOREINFO_NUMBER() is, at least originally, intended
> > to be used for a small *unsigned* integer.
> 
> Not sure..When I see all the places where it has been used, it seems it can
> accommodate *long* variable.

I don't know makedumpfile side, but as far as I look at the kernel code
in crash_save_vmcoreinfo_init(), all the values seem to be small positive
numbers.

> See, read_vmcoreinfo_long() of makedumpfile [1] , which is being used to read
> "NUMBER" string.  This function uses strtol(). So I think, we must have 
> similar
> implementation if we intend to use VMCOREINFO_NUMBER().
> 
> [1] 
> https://sourceforge.net/p/makedumpfile/code/ci/master/tree/makedumpfile.c#l2400
> 
> > 
> > I also know that PHYS_OFFSET can now be nagative in v4.6 on arm64.
> > Yet I'm thinking of adding "0x" as a prefix to VMCOREINOF string.
> 
> I think, we should not change existing VMCOREINFO_() macros of kernel,
> because it will break the applications which rely on it's current structure.

I'm not saying that we change VMCOREINFO_NUMBER() macro.

> ATM, I also do not see any urgency of defining a new macro which can have
> implementation like vmcoreinfo_append_str("NUMBER(X)=%#llx\n", X), because
> exiting macros is able to take care of the needs.
> 
> > 
> > -Takahiro AKASHI
> > 
> > > I will suggest to take following modification in crash code:
> > > 
> > > diff --git a/arm64.c b/arm64.c
> > > index 6b97093..9397d6d 100644
> > > --- a/arm64.c
> > > +++ b/arm64.c
> > > @@ -122,7 +122,7 @@ arm64_init(int when)
> > > ms = machdep->machspec;
> > > if (!ms->kimage_voffset &&
> > > (string = 
> > > pc->read_vmcoreinfo("NUMBER(kimage_voffset)"))) {
> > > -   ms->kimage_voffset = htol(string, QUIET, NULL);
> > > +   ms->kimage_voffset = dtol(string, QUIET, NULL);
> > > free(string);
> > > }
> > > 
> > > diff --git a/tools.c b/tools.c
> > > index 384bebd..1383e43 100644
> > > --- a/tools.c
> > > +++ b/tools.c
> > > @@ -877,7 +877,7 @@ dtol(char *s, int flags, int *errptr)
> > >  s++;
> > > 
> > >  for (j = 0; s[j] != '\0'; j++)
> > > -if ((s[j] < '0' || s[j] > '9'))
> > > +if ( (s[j] != '-') && ((s[j] < '0' || s[j] > '9')))
> > >  break ;
> > > 
> > > if (s[j] != '\0') {
> > > 
> 
> ~Pratyush

-- 
Thanks,
-Takahiro AKASHI

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[Pratyush Anand]

On 27/05/2016:01:03:56 PM, AKASHI Takahiro wrote:
> On Thu, May 26, 2016 at 03:09:55PM +0530, Pratyush Anand wrote:
> > On 26/05/2016:05:13:30 PM, AKASHI Takahiro wrote:
> > > On Wed, May 25, 2016 at 10:28:10AM -0400, Dave Anderson wrote:
> > 
> > [...]
> > 
> > > > > (This is the reason that I don't think we need a VMCOREINFO for
> > > > > CONFIG_RANDOMIZE_BASE.)
> > > > 
> > > > Well, as long as there's a way to avoid that unnecessary/confusing
> > > > warning message for non-KASLR new-vmemmap kernels.
> > > > 
> > > > I also wonder whether makedumpfile could use it?
> > > 
> > > -> Pratyush?
> > 
> > Since  second kernel's initrd cannot include a large file like VMLINUX, so
> > makedumpfile should also work without passing '-x vmlinux'.  Therefore,
> > makedumpfile will need some minimal symbol's values to be passed in vmcore.
> 
> I understand.
> (but I wonder why makedumpfile doesn't utilize System.map nor .config.)

So far makedumpfile has been designed to work only with vmcore as input in it's
minimal form (specially in second kernel).
+Atsushi & makedumpfile list: He will have better idea about it.

Moreover, there are few variables, whose values are needed in order to translate
phys to virt and vice versa. So, passing their symbol address would not be of
much help. For example, we need to know value of kimage_voffset for __pa(), and
so symbol address of kimage_voffset will not help.

> 
> > IIUC, then you need to pass CONFIG_RANDOMIZE_BASE in order to calculate
> > PHYS_OFFSET. If yes, then why not to pass PHYS_OFFSET itself into vmcore.
> 
> No, as I said in the discussions, I don't think that we need
> CONFIG_RANDOMIZE_BASE *if* we can read a kernel symbol's value
> from /proc/vmcore.

What I understand that, we can read only those symbols/variables from vmcore
which have been embedded using VMCOREINFO_ macros (if we do not pass
vmlinux, like in second kernel). Atsushi, please correct me if I am wrong.

> 
> > Following numbers in vmcore [1] is helping me out in implementing __pa() and
> > __va() for all page table sizes and levels.
> > 
> > VMCOREINFO_NUMBER(pgtable_levels);
> > VMCOREINFO_NUMBER(va_bits);
> > VMCOREINFO_NUMBER(page_shift);
> 
> Since We already have VMCOREINFO(PAGESIZE), we won't nedd page_shift.

Yes, agreed.

> As well, pgtable_levels can be determined by va_bits and PAGESIZE.
> See arch/arm64/Kconfig.

Yes, agreed.

> 
> > VMCOREINFO_NUMBER(phys_offset);
> > VMCOREINFO_NUMBER(config_kasan);
> 
> Let me ask some questions.
> * What kind of data in vmcore and how does makedumpfile access
>   without vmlinux nor System.map?

Well, I do not have the deep idea, again Atsushi can help here.

makedumpfile mainly compresses vmcore (ram image of panicked kernel),
additionally it also excludes unnecessary pages for analysis. It will need
symbol information to exclude unnecessary pages, where vmlinux is needed mainly.
So, normally we do not perform erase(exclude) functionality in second kernel. It
is being performed latter, on a compressed dumpfile.

> * Why do you need CONFIG_KASAN?

KASAN_SHADOW_SIZE is dependent on CONFIG_KASAN.
MODULES_VADDR is dependent on KASAN_SHADOW_SIZE.

We need MODULES_VADDR,VMALLOC_START,VMEMMAP_START and their END addresses in
order to define whether a virtual to physical translation can be obtained using
linear mapping or need to read from page table instead.

Thanks for the questions and inputs.  Those are helpful. :-)
~Pratyush
> 
> Thanks,
> -Takahiro AKASHI
> 
> > VMCOREINFO_NUMBER(kimage_voffset);
> > 
> > ~Pratyush
> > 
> > [1]
> > https://github.com/pratyushanand/linux/blob/7011e478aae3e568cc8dca15b6c128fe728416f7/arch/arm64/kernel/machine_kexec.c#L275
> > 
> > --
> > Crash-utility mailing list
> > Crash-utility@redhat.com
> > https://www.redhat.com/mailman/listinfo/crash-utility
> 
> -- 
> Thanks,
> -Takahiro AKASHI
> 
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[AKASHI Takahiro]

On Thu, May 26, 2016 at 03:09:55PM +0530, Pratyush Anand wrote:
> On 26/05/2016:05:13:30 PM, AKASHI Takahiro wrote:
> > On Wed, May 25, 2016 at 10:28:10AM -0400, Dave Anderson wrote:
> 
> [...]
> 
> > > > (This is the reason that I don't think we need a VMCOREINFO for
> > > > CONFIG_RANDOMIZE_BASE.)
> > > 
> > > Well, as long as there's a way to avoid that unnecessary/confusing
> > > warning message for non-KASLR new-vmemmap kernels.
> > > 
> > > I also wonder whether makedumpfile could use it?
> > 
> > -> Pratyush?
> 
> Since  second kernel's initrd cannot include a large file like VMLINUX, so
> makedumpfile should also work without passing '-x vmlinux'.  Therefore,
> makedumpfile will need some minimal symbol's values to be passed in vmcore.

I understand.
(but I wonder why makedumpfile doesn't utilize System.map nor .config.)

> IIUC, then you need to pass CONFIG_RANDOMIZE_BASE in order to calculate
> PHYS_OFFSET. If yes, then why not to pass PHYS_OFFSET itself into vmcore.

No, as I said in the discussions, I don't think that we need
CONFIG_RANDOMIZE_BASE *if* we can read a kernel symbol's value
from /proc/vmcore.

> Following numbers in vmcore [1] is helping me out in implementing __pa() and
> __va() for all page table sizes and levels.
> 
> VMCOREINFO_NUMBER(pgtable_levels);
> VMCOREINFO_NUMBER(va_bits);
> VMCOREINFO_NUMBER(page_shift);

Since We already have VMCOREINFO(PAGESIZE), we won't nedd page_shift.
As well, pgtable_levels can be determined by va_bits and PAGESIZE.
See arch/arm64/Kconfig.

> VMCOREINFO_NUMBER(phys_offset);
> VMCOREINFO_NUMBER(config_kasan);

Let me ask some questions.
* What kind of data in vmcore and how does makedumpfile access
  without vmlinux nor System.map?
* Why do you need CONFIG_KASAN?

Thanks,
-Takahiro AKASHI

> VMCOREINFO_NUMBER(kimage_voffset);
> 
> ~Pratyush
> 
> [1]
> https://github.com/pratyushanand/linux/blob/7011e478aae3e568cc8dca15b6c128fe728416f7/arch/arm64/kernel/machine_kexec.c#L275
> 
> --
> Crash-utility mailing list
> Crash-utility@redhat.com
> https://www.redhat.com/mailman/listinfo/crash-utility

-- 
Thanks,
-Takahiro AKASHI

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[AKASHI Takahiro]

On Thu, May 26, 2016 at 01:27:08PM +0530, Pratyush Anand wrote:
> On 26/05/2016:04:04:08 PM, AKASHI Takahiro wrote:
> > Pratyush,
> > 
> > Just for debug purpose.
> > Please add the following line to *your* arch_crash_save_vmcoreinfo():
> > > vmcoreinfo_append_str("NUMBER(kimage_voffset)=%llx\n", kimage_voffset);
> 
> Thanks for the pointer.
> 
> I did had VMCOREINFO_NUMBER(kimage_voffset) in arch_crash_save_vmcoreinfo().
> 
> https://github.com/pratyushanand/linux/commit/7011e478aae3e568cc8dca15b6c128fe728416f7#diff-cdf29c3b9471b9d813afc107dd154acdR291
> 
> But, I noticed that in crash code you have "ms->kimage_voffset = htol(string,
> QUIET, NULL);". So, the change you have suggested will work.

I know that. It is intentional.

> However, I think its preferable to use VMCOREINFO_NUMBER() macro instead.
> makedumpfile is able to calculate kimage_voffset correctly with that without 
> any
> issue.

I think that VMCOREINFO_NUMBER() is, at least originally, intended
to be used for a small *unsigned* integer.

I also know that PHYS_OFFSET can now be nagative in v4.6 on arm64.
Yet I'm thinking of adding "0x" as a prefix to VMCOREINOF string.

-Takahiro AKASHI

> I will suggest to take following modification in crash code:
> 
> diff --git a/arm64.c b/arm64.c
> index 6b97093..9397d6d 100644
> --- a/arm64.c
> +++ b/arm64.c
> @@ -122,7 +122,7 @@ arm64_init(int when)
> ms = machdep->machspec;
> if (!ms->kimage_voffset &&
> (string = pc->read_vmcoreinfo("NUMBER(kimage_voffset)"))) 
> {
> -   ms->kimage_voffset = htol(string, QUIET, NULL);
> +   ms->kimage_voffset = dtol(string, QUIET, NULL);
> free(string);
> }
> 
> diff --git a/tools.c b/tools.c
> index 384bebd..1383e43 100644
> --- a/tools.c
> +++ b/tools.c
> @@ -877,7 +877,7 @@ dtol(char *s, int flags, int *errptr)
>  s++;
> 
>  for (j = 0; s[j] != '\0'; j++)
> -if ((s[j] < '0' || s[j] > '9'))
> +if ( (s[j] != '-') && ((s[j] < '0' || s[j] > '9')))
>  break ;
> 
> if (s[j] != '\0') {
> 
> ~Pratyush
> 
> > 
> > I will add this to my next kdump patch.
> > 
> > Thanks,
> > -Takahiro AKASHI
> > 
> > 
> > On Thu, May 26, 2016 at 10:58:24AM +0530, Pratyush Anand wrote:
> > > On 24/05/2016:01:59:06 PM, Dave Anderson wrote:
> > > > 
> > > > 
> > > > - Original Message -
> > > > > Yet some issues, but ...
> > > > >
> > > > 
> > > > Hi Takahiro,
> > > > 
> > > > Here are my general comments on my testing of the v2 patch, followed 
> > > > by a few comments in the patch itself. 
> > > > 
> > > > First, the combination of the new memory map layout and KASLR is 
> > > > somewhat
> > > > confusing.  I am testing your patch on a 4.6.0-0.rc7.git2.1.fc25 kernel
> > > > that has this configuration:
> > > > 
> > > >   config-arm64:# CONFIG_RANDOMIZE_BASE is not set
> > > > 
> > > > So KASLR doesn't really enter into the picture.  But when bringing
> > > > up the crash session, it shows the "kaslr kernel" WARNING:
> > > > 
> > > >   # ./crash
> > > >   
> > > >   crash 7.1.5++
> > > >   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.
> > > >
> > > >   WARNING: kimage_voffset not identified for kaslr kernel
> > > >   GNU gdb (GDB) 7.6
> > > >   Copyright (C) 2013 Free Software Foundation, Inc.
> > > >   License GPLv3+: GNU GPL version 3 or later 
> > > > 
> > > >   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 "aarch64-unknown-linux-gnu"...
> > > >   
> > > > KERNEL: 
> > > > /usr/lib/debug/lib/modules/4.6.0-0.rc7.git2.1.fc25.aarch64/vmlinux
> > > >   DUMPFILE: /dev/crash
> > > >   CPUS: 8
> > > >   DATE: Tue May 24 10:08:08 2016
> > > > UPTIME: 11 days, 18:32:41
> > > >   LOAD AVERAGE: 0.17, 0.09, 0.12
> > > >  TASKS: 197
> > > >   NODENAME: apm-mustang-ev3-36.khw.lab.eng.bos.redhat.com
> > > >RELEASE: 

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[Dave Anderson]

- Original Message -

> > > > > 3) Backtracing a 'panic'ed task fails:
> > > > >  crash> bt
> > > > >  PID: 999TASK: ffe960081800  CPU: 0   COMMAND: "sh"
> > > > >  bt: WARNING: corrupt prstatus? pstate=0x8000, but no user frame 
> > > > > found
> > > > >  bt: WARNING: cannot determine starting stack frame for task 
> > > > > ffe960081800
> > > > > 
> > > > >   frame->pc indicates that it is a kernel address, so obviously 
> > > > > something
> > > > >   is wrong. I'm diggin into it.
> > > > 
> > > > Can you add a debug statement that displays frame->pc, frame->sp, and 
> > > > frame->fp?
> > > 
> > > I've already identified the cause.
> > > pt_regs->pstate was set mistakenly from "sprsr_el1" in panic().
> > > But I have a difficulty here to fix the problem as we have no direct way
> > > to retrieve a value of the *current* PSTATE.
> >  
> > Interesting.  I don't know what you mean by "sprsr_el1" in panic(), but

> > I just got a report from my github "issues", where the user injected a 
> > panic()
> > call into a kernel module and got the same error as above because of the 
> > pstate
> > value.  I asked him to put this hack into arm64.c:
> 
> spspr_el1 is a register that holds a value of PSTATE when an exception
> is trapped into EL1. Since panic() is called even in case of software
> bugs, it is not useful anyway.
> Currently I'm trying to save a "faked" current PSTATE into pt_regs->pstate
> and will add this fix in my next kdump patch series (v17).

OK thanks.  Mystery solved.  I think I'll still add the hack-around that prints
the warning message but allows it to continue if the sp, fp and pc appear 
correct.
It used to do that, but the new behavior was actually a regression that was 
introduced as part of this patch in crash-7.1.5:

Fix for the "bt" command to properly pull the stack and frame pointer
registers from the NT_PRSTATUS notes of 32-bit tasks running in
user-mode on ARM64.  Without the patch, the "bt" command utilizes
ptregs->sp and ptregs->regs[29] for 32-bit tasks instead of the
architecturally-mapped ptregs->regs[13] and ptregs->regs[11], which
yields unpredictable/invalid results, and possibly a segmentation
violation.
(drjo...@redhat.com)

Thanks,
  Dave






--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[Pratyush Anand]

On 26/05/2016:05:13:30 PM, AKASHI Takahiro wrote:
> On Wed, May 25, 2016 at 10:28:10AM -0400, Dave Anderson wrote:

[...]

> > > (This is the reason that I don't think we need a VMCOREINFO for
> > > CONFIG_RANDOMIZE_BASE.)
> > 
> > Well, as long as there's a way to avoid that unnecessary/confusing
> > warning message for non-KASLR new-vmemmap kernels.
> > 
> > I also wonder whether makedumpfile could use it?
> 
> -> Pratyush?

Since  second kernel's initrd cannot include a large file like VMLINUX, so
makedumpfile should also work without passing '-x vmlinux'.  Therefore,
makedumpfile will need some minimal symbol's values to be passed in vmcore.

IIUC, then you need to pass CONFIG_RANDOMIZE_BASE in order to calculate
PHYS_OFFSET. If yes, then why not to pass PHYS_OFFSET itself into vmcore.

Following numbers in vmcore [1] is helping me out in implementing __pa() and
__va() for all page table sizes and levels.

VMCOREINFO_NUMBER(pgtable_levels);
VMCOREINFO_NUMBER(va_bits);
VMCOREINFO_NUMBER(page_shift);
VMCOREINFO_NUMBER(phys_offset);
VMCOREINFO_NUMBER(config_kasan);
VMCOREINFO_NUMBER(kimage_voffset);

~Pratyush

[1]
https://github.com/pratyushanand/linux/blob/7011e478aae3e568cc8dca15b6c128fe728416f7/arch/arm64/kernel/machine_kexec.c#L275

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[AKASHI Takahiro]

On Wed, May 25, 2016 at 10:28:10AM -0400, Dave Anderson wrote:
> 
> - Original Message -
> > On Tue, May 24, 2016 at 01:59:06PM -0400, Dave Anderson wrote:
> > > 
> > > - Original Message -
> > > > Yet some issues, but ...
> > > >
> > > 
> > > Hi Takahiro,
> > > 
> > > Here are my general comments on my testing of the v2 patch, followed
> > > by a few comments in the patch itself.
> > 
> > Thank you for your quick review/testing, again.
> > 
> > > First, the combination of the new memory map layout and KASLR is somewhat
> > > confusing.  I am testing your patch on a 4.6.0-0.rc7.git2.1.fc25 kernel
> > > that has this configuration:
> > 
> > Right. I use the "kaslr kernel" or "kaslr-enabled kernel" in two
> > meanings (almost interchangeably):
> >- kernel with a new memory map, that is v4.6 or later
> >- kernel that has ability of KASLR (configured with CONFIG_RANDOMIZE_RAM)
> > 
> > When we talked offline, you mentioned the possibility of backporting
> > KASLR to older kernel, so I hesitated to use "v4.6 or later".
> > But I think that we'd better use "v4.6 or later" for a clarification
> > for now.
>  
> Actually I was thinking more along the lines of the new vmemmap stuff
> being backported.  But it looks like that would be impossible without
> also bringing along "kimage_voffset".  

Yeah, a sbustantial amount of code on mm code must be changed, and it is
impractical to backport them.

> 
> > >   config-arm64:# CONFIG_RANDOMIZE_BASE is not set
> > > 
> > > So KASLR doesn't really enter into the picture.  But when bringing
> > > up the crash session, it shows the "kaslr kernel" WARNING:
> > > 
> > >   # ./crash
> > >   
> > >   crash 7.1.5++
> > >   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.
> > >
> > >   WARNING: kimage_voffset not identified for kaslr kernel
> > >   GNU gdb (GDB) 7.6
> > >   Copyright (C) 2013 Free Software Foundation, Inc.
> > >   License GPLv3+: GNU GPL version 3 or later
> > >   
> > >   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 "aarch64-unknown-linux-gnu"...
> > >   
> > > KERNEL:
> > > /usr/lib/debug/lib/modules/4.6.0-0.rc7.git2.1.fc25.aarch64/vmlinux
> > >   DUMPFILE: /dev/crash
> > >   CPUS: 8
> > >   DATE: Tue May 24 10:08:08 2016
> > > UPTIME: 11 days, 18:32:41
> > >   LOAD AVERAGE: 0.17, 0.09, 0.12
> > >  TASKS: 197
> > >   NODENAME: apm-mustang-ev3-36.khw.lab.eng.bos.redhat.com
> > >RELEASE: 4.6.0-0.rc7.git2.1.fc25.aarch64
> > >VERSION: #1 SMP Thu May 12 13:28:43 UTC 2016
> > >MACHINE: aarch64  (unknown Mhz)
> > > MEMORY: 16 GB
> > >PID: 7556
> > >COMMAND: "crash"
> > >   TASK: fe00beb45400  [THREAD_INFO: fe00beb98000]
> > >CPU: 7
> > >  STATE: TASK_RUNNING (ACTIVE)
> > >   
> > >   crash>
> > >   
> > > Why show that WARNING in this case?  I understant that it's not
> > > stashed during early initialization:
> > 
> > If we don't know kimage_voffset, we can't analyze the contents of
> > memory (live or kdump).
> 
> I understand.  But clearly that's not the case with my system above that
> does not have CONFIG_RANDOMIZE_BASE configured, so the warning message
> is nonsensical/confusing.  That's why I was speculating about perhaps
> having kdump export a VMCOREINFO_CONFIG(RANDOMIZE_BASE) so that it is 
> readily apparent.
> 
> > 
> > >   crash> help -m
> > >  flags: 104000c5
> > >  
> > > (KSYMS_START|VM_L2_64K|VMEMMAP|IRQ_STACKS|MACHDEP_BT_TEXT|NEW_VMEMMAP)
> > >   ... [ cut ] ...
> > >memory map layout: new  <--- BTW, this is
> > >redundant/not-a-member, and we've got NEW_VMEMMAP
> > >  VA_BITS: 42
> > >userspace_top: 0400
> > >  page_offset: fe00
> > >   vmalloc_start_addr: fc000800
> > >  vmalloc_end: fdff5ffe
> > >modules_vaddr: fc00
> > >  modules_end: 

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[Pratyush Anand]

On 26/05/2016:04:04:08 PM, AKASHI Takahiro wrote:
> Pratyush,
> 
> Just for debug purpose.
> Please add the following line to *your* arch_crash_save_vmcoreinfo():
> > vmcoreinfo_append_str("NUMBER(kimage_voffset)=%llx\n", kimage_voffset);

Thanks for the pointer.

I did had VMCOREINFO_NUMBER(kimage_voffset) in arch_crash_save_vmcoreinfo().

https://github.com/pratyushanand/linux/commit/7011e478aae3e568cc8dca15b6c128fe728416f7#diff-cdf29c3b9471b9d813afc107dd154acdR291

But, I noticed that in crash code you have "ms->kimage_voffset = htol(string,
QUIET, NULL);". So, the change you have suggested will work.

However, I think its preferable to use VMCOREINFO_NUMBER() macro instead.
makedumpfile is able to calculate kimage_voffset correctly with that without any
issue.

I will suggest to take following modification in crash code:

diff --git a/arm64.c b/arm64.c
index 6b97093..9397d6d 100644
--- a/arm64.c
+++ b/arm64.c
@@ -122,7 +122,7 @@ arm64_init(int when)
ms = machdep->machspec;
if (!ms->kimage_voffset &&
(string = pc->read_vmcoreinfo("NUMBER(kimage_voffset)"))) {
-   ms->kimage_voffset = htol(string, QUIET, NULL);
+   ms->kimage_voffset = dtol(string, QUIET, NULL);
free(string);
}

diff --git a/tools.c b/tools.c
index 384bebd..1383e43 100644
--- a/tools.c
+++ b/tools.c
@@ -877,7 +877,7 @@ dtol(char *s, int flags, int *errptr)
 s++;

 for (j = 0; s[j] != '\0'; j++)
-if ((s[j] < '0' || s[j] > '9'))
+if ( (s[j] != '-') && ((s[j] < '0' || s[j] > '9')))
 break ;

if (s[j] != '\0') {

~Pratyush

> 
> I will add this to my next kdump patch.
> 
> Thanks,
> -Takahiro AKASHI
> 
> 
> On Thu, May 26, 2016 at 10:58:24AM +0530, Pratyush Anand wrote:
> > On 24/05/2016:01:59:06 PM, Dave Anderson wrote:
> > > 
> > > 
> > > - Original Message -
> > > > Yet some issues, but ...
> > > >
> > > 
> > > Hi Takahiro,
> > > 
> > > Here are my general comments on my testing of the v2 patch, followed 
> > > by a few comments in the patch itself. 
> > > 
> > > First, the combination of the new memory map layout and KASLR is somewhat
> > > confusing.  I am testing your patch on a 4.6.0-0.rc7.git2.1.fc25 kernel
> > > that has this configuration:
> > > 
> > >   config-arm64:# CONFIG_RANDOMIZE_BASE is not set
> > > 
> > > So KASLR doesn't really enter into the picture.  But when bringing
> > > up the crash session, it shows the "kaslr kernel" WARNING:
> > > 
> > >   # ./crash
> > >   
> > >   crash 7.1.5++
> > >   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.
> > >
> > >   WARNING: kimage_voffset not identified for kaslr kernel
> > >   GNU gdb (GDB) 7.6
> > >   Copyright (C) 2013 Free Software Foundation, Inc.
> > >   License GPLv3+: GNU GPL version 3 or later 
> > > 
> > >   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 "aarch64-unknown-linux-gnu"...
> > >   
> > > KERNEL: 
> > > /usr/lib/debug/lib/modules/4.6.0-0.rc7.git2.1.fc25.aarch64/vmlinux
> > >   DUMPFILE: /dev/crash
> > >   CPUS: 8
> > >   DATE: Tue May 24 10:08:08 2016
> > > UPTIME: 11 days, 18:32:41
> > >   LOAD AVERAGE: 0.17, 0.09, 0.12
> > >  TASKS: 197
> > >   NODENAME: apm-mustang-ev3-36.khw.lab.eng.bos.redhat.com
> > >RELEASE: 4.6.0-0.rc7.git2.1.fc25.aarch64
> > >VERSION: #1 SMP Thu May 12 13:28:43 UTC 2016
> > >MACHINE: aarch64  (unknown Mhz)
> > > MEMORY: 16 GB
> > >PID: 7556
> > >COMMAND: "crash"
> > >   TASK: fe00beb45400  [THREAD_INFO: fe00beb98000]
> > >CPU: 7
> > >  STATE: TASK_RUNNING (ACTIVE)
> > >   
> > >   crash>
> > 
> > Do not know whats missing, I am yet not able to reach "crash>" prompt. I 
> > have
> > crash utility having this patch on top of "commit
> > 8ceb1ac628bf6a0a7f0bbfff030ec93081bca4cd" [1]. I have kernel code 
> > v4.6+kexec-v15 

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[Pratyush Anand]

On 24/05/2016:01:59:06 PM, Dave Anderson wrote:
> 
> 
> - Original Message -
> > Yet some issues, but ...
> >
> 
> Hi Takahiro,
> 
> Here are my general comments on my testing of the v2 patch, followed 
> by a few comments in the patch itself. 
> 
> First, the combination of the new memory map layout and KASLR is somewhat
> confusing.  I am testing your patch on a 4.6.0-0.rc7.git2.1.fc25 kernel
> that has this configuration:
> 
>   config-arm64:# CONFIG_RANDOMIZE_BASE is not set
> 
> So KASLR doesn't really enter into the picture.  But when bringing
> up the crash session, it shows the "kaslr kernel" WARNING:
> 
>   # ./crash
>   
>   crash 7.1.5++
>   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.
>
>   WARNING: kimage_voffset not identified for kaslr kernel
>   GNU gdb (GDB) 7.6
>   Copyright (C) 2013 Free Software Foundation, Inc.
>   License GPLv3+: GNU GPL version 3 or later 
> 
>   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 "aarch64-unknown-linux-gnu"...
>   
> KERNEL: 
> /usr/lib/debug/lib/modules/4.6.0-0.rc7.git2.1.fc25.aarch64/vmlinux
>   DUMPFILE: /dev/crash
>   CPUS: 8
>   DATE: Tue May 24 10:08:08 2016
> UPTIME: 11 days, 18:32:41
>   LOAD AVERAGE: 0.17, 0.09, 0.12
>  TASKS: 197
>   NODENAME: apm-mustang-ev3-36.khw.lab.eng.bos.redhat.com
>RELEASE: 4.6.0-0.rc7.git2.1.fc25.aarch64
>VERSION: #1 SMP Thu May 12 13:28:43 UTC 2016
>MACHINE: aarch64  (unknown Mhz)
> MEMORY: 16 GB
>PID: 7556
>COMMAND: "crash"
>   TASK: fe00beb45400  [THREAD_INFO: fe00beb98000]
>CPU: 7
>  STATE: TASK_RUNNING (ACTIVE)
>   
>   crash>

Do not know whats missing, I am yet not able to reach "crash>" prompt. I have
crash utility having this patch on top of "commit
8ceb1ac628bf6a0a7f0bbfff030ec93081bca4cd" [1]. I have kernel code 
v4.6+kexec-v15 [2].

In my .config:
# CONFIG_KASAN is not set
# CONFIG_RANDOMIZE_BASE is not set

This is what I get:

[root@dhcppc15 crash]# ./crash /lib/modules/4.6.0+/build/vmlinux 
/var/crash/127.0.0.1-2016-05-26-09\:40\:05/vmcore

crash 7.1.5++
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 
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 "aarch64-unknown-linux-gnu"...

crash: read error: kernel virtual address: fc0008b80fd8  type: "possible"
WARNING: cannot read cpu_possible_map
crash: read error: kernel virtual address: fc0008b80dd8  type: "present"
WARNING: cannot read cpu_present_map
crash: read error: kernel virtual address: fc0008b80bd8  type: "online"
WARNING: cannot read cpu_online_map
crash: read error: kernel virtual address: fc0008b811d8  type: "active"
WARNING: cannot read cpu_active_map
crash: read error: kernel virtual address: fc00091f6c78  type: 
"shadow_timekeeper xtime_sec"
crash: read error: kernel virtual address: fc0008b9223c  type: "init_uts_ns"
crash: /lib/modules/4.6.0+/build/vmlinux and 
/var/crash/127.0.0.1-2016-05-26-09:40:05/vmcore do not match!

Usage:

  crash [OPTION]... NAMELIST MEMORY-IMAGE[@ADDRESS] (dumpfile form)
  crash [OPTION]... [NAMELIST]  (live 

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[Dave Anderson]

- Original Message -
> > 
> > Are you using a mainline kernel (final v4.6, not -rcX)?
> 
> Good point.  When I configured my arm64 test system, I installed the latest
> Fedora kernel available at the time (4.6.0-0.rc7.git2.1.fc25), but it is based
> upon linux-4.5.tar.xz.  I see now that there is a kernel-4.6.0-1.fc25 
> available
> that is based upon linux-4.6.tar.xz.  I'll update the system.

Here's the output from the updated non-randomized live system:
  
  crash> sys
KERNEL: /usr/lib/debug/lib/modules/4.6.0-1.fc25.aarch64/vmlinux
  DUMPFILE: /dev/crash
  CPUS: 8
  DATE: Wed May 25 11:30:06 2016
UPTIME: 00:18:43
  LOAD AVERAGE: 0.01, 0.14, 0.17
 TASKS: 200
  NODENAME: apm-mustang-ev3-36.khw.lab.eng.bos.redhat.com
   RELEASE: 4.6.0-1.fc25.aarch64
   VERSION: #1 SMP Mon May 16 23:11:08 UTC 2016
   MACHINE: aarch64  (unknown Mhz)
MEMORY: 16 GB
  crash> log
  ... [ cut ] ...
  [0.00] Virtual kernel memory layout:
  [0.00] modules : 0xfc00 - 0xfc000800   (   
128 MB)
  [0.00] vmalloc : 0xfc000800 - 0xfdfedfff   (  
2043 GB)
  [0.00]   .text : 0xfc000808 - 0xfc000889   (  
8256 KB)
 .rodata : 0xfc000889 - 0xfc0008c1   (  
3584 KB)
   .init : 0xfc0008c1 - 0xfc0008d5   (  
1280 KB)
   .data : 0xfc0008d5 - 0xfc0008eaac00   (  
1387 KB)
  [0.00] vmemmap : 0xfdfee000 - 0xfdffe000   ( 
4 GB maximum)
   0xfdfee000 - 0xfdfee100   (
16 MB actual)
  [0.00] fixed   : 0xfdfffe7d - 0xfdfffec0   (  
4288 KB)
  [0.00] PCI I/O : 0xfdfffee0 - 0xfde0   (
16 MB)
  [0.00] memory  : 0xfe00 - 0xfe04   ( 
16384 MB)
  ...
  
The starting addresses are OK, but still the vmemmap range looks suspect:
  
  crash> help -m
  ... [ cut ] ...
 VA_BITS: 42
   userspace_top: 0400
 page_offset: fe00
  vmalloc_start_addr: fc000800
 vmalloc_end: fdff5ffe
   modules_vaddr: fc00
 modules_end: fc0007ff
   vmemmap_vaddr: fdff8000  ???
 vmemmap_end: fdff
 kimage_text: fc000808
  kimage_end: fc000907
  kimage_voffset: 
 phys_offset: 40
  ...

  crash> kmem fdff8000
  kmem: WARNING: cannot make virtual-to-physical translation: fdff8000
  fdff8000: kernel virtual address not found in mem map
  crash>
  
The vmemmap address from the log reads OK:

  crash> kmem -p | head -10
PAGE   PHYSICAL  MAPPING   INDEX CNT FLAGS
  fdfee000   40 fe03dc99f430   1b  2 4003c 
referenced,uptodate,dirty,lru,swapbacked
  fdfee040   41 fe03dc99f430   1c  2 4003c 
referenced,uptodate,dirty,lru,swapbacked
  fdfee080   42 fe03dc99f430   1d  2 4003c 
referenced,uptodate,dirty,lru,swapbacked
  fdfee0c0   43 fe03dc99f430   1e  2 4003c 
referenced,uptodate,dirty,lru,swapbacked
  fdfee100   44 fe03dc99f430   1f  2 4003c 
referenced,uptodate,dirty,lru,swapbacked
  fdfee140   45 fe03dc99f430   20  2 40078 
uptodate,dirty,lru,active,swapbacked
  fdfee180   46 fe03dc99f430   21  2 4003c 
referenced,uptodate,dirty,lru,swapbacked
  fdfee1c0   47 fe03dc99f430   22  2 40078 
uptodate,dirty,lru,active,swapbacked
  fdfee200   4800  1 400 reserved
  ... [ cut ] ...
  fdfee0fffd80   43fff600  1 
4400 reserved
  fdfee0fffdc0   43fff700  1 
4400 reserved
  fdfee0fffe00   43fff800  1 
4400 reserved
  fdfee0fffe40   43fff900  1 
4400 reserved
  fdfee0fffe80   43fffa00  1 
4400 reserved
  fdfee0fffec0   43fffb00  1 
4400 reserved
  fdfee000   43fffc00  1 
4400 reserved
  fdfee040   43fffd00  1 
4400 reserved
  fdfee080   43fffe00  1 
4400 reserved
  fdfee0c0   4300  1 
4400 reserved
  crash>


And again, the page_offset is fe00 with a kernel VA_BITS 
configuration of 42:

  

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[Dave Anderson]

- Original Message -
> On Tue, May 24, 2016 at 01:59:06PM -0400, Dave Anderson wrote:
> > 
> > - Original Message -
> > > Yet some issues, but ...
> > >
> > 
> > Hi Takahiro,
> > 
> > Here are my general comments on my testing of the v2 patch, followed
> > by a few comments in the patch itself.
> 
> Thank you for your quick review/testing, again.
> 
> > First, the combination of the new memory map layout and KASLR is somewhat
> > confusing.  I am testing your patch on a 4.6.0-0.rc7.git2.1.fc25 kernel
> > that has this configuration:
> 
> Right. I use the "kaslr kernel" or "kaslr-enabled kernel" in two
> meanings (almost interchangeably):
>- kernel with a new memory map, that is v4.6 or later
>- kernel that has ability of KASLR (configured with CONFIG_RANDOMIZE_RAM)
> 
> When we talked offline, you mentioned the possibility of backporting
> KASLR to older kernel, so I hesitated to use "v4.6 or later".
> But I think that we'd better use "v4.6 or later" for a clarification
> for now.
 
Actually I was thinking more along the lines of the new vmemmap stuff
being backported.  But it looks like that would be impossible without
also bringing along "kimage_voffset".  


> >   config-arm64:# CONFIG_RANDOMIZE_BASE is not set
> > 
> > So KASLR doesn't really enter into the picture.  But when bringing
> > up the crash session, it shows the "kaslr kernel" WARNING:
> > 
> >   # ./crash
> >   
> >   crash 7.1.5++
> >   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.
> >
> >   WARNING: kimage_voffset not identified for kaslr kernel
> >   GNU gdb (GDB) 7.6
> >   Copyright (C) 2013 Free Software Foundation, Inc.
> >   License GPLv3+: GNU GPL version 3 or later
> >   
> >   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 "aarch64-unknown-linux-gnu"...
> >   
> > KERNEL:
> > /usr/lib/debug/lib/modules/4.6.0-0.rc7.git2.1.fc25.aarch64/vmlinux
> >   DUMPFILE: /dev/crash
> >   CPUS: 8
> >   DATE: Tue May 24 10:08:08 2016
> > UPTIME: 11 days, 18:32:41
> >   LOAD AVERAGE: 0.17, 0.09, 0.12
> >  TASKS: 197
> >   NODENAME: apm-mustang-ev3-36.khw.lab.eng.bos.redhat.com
> >RELEASE: 4.6.0-0.rc7.git2.1.fc25.aarch64
> >VERSION: #1 SMP Thu May 12 13:28:43 UTC 2016
> >MACHINE: aarch64  (unknown Mhz)
> > MEMORY: 16 GB
> >PID: 7556
> >COMMAND: "crash"
> >   TASK: fe00beb45400  [THREAD_INFO: fe00beb98000]
> >CPU: 7
> >  STATE: TASK_RUNNING (ACTIVE)
> >   
> >   crash>
> >   
> > Why show that WARNING in this case?  I understant that it's not
> > stashed during early initialization:
> 
> If we don't know kimage_voffset, we can't analyze the contents of
> memory (live or kdump).

I understand.  But clearly that's not the case with my system above that
does not have CONFIG_RANDOMIZE_BASE configured, so the warning message
is nonsensical/confusing.  That's why I was speculating about perhaps
having kdump export a VMCOREINFO_CONFIG(RANDOMIZE_BASE) so that it is 
readily apparent.

> 
> >   crash> help -m
> >  flags: 104000c5
> >  
> > (KSYMS_START|VM_L2_64K|VMEMMAP|IRQ_STACKS|MACHDEP_BT_TEXT|NEW_VMEMMAP)
> >   ... [ cut ] ...
> >memory map layout: new  <--- BTW, this is
> >redundant/not-a-member, and we've got NEW_VMEMMAP
> >  VA_BITS: 42
> >userspace_top: 0400
> >  page_offset: fe00
> >   vmalloc_start_addr: fc000800
> >  vmalloc_end: fdff5ffe
> >modules_vaddr: fc00
> >  modules_end: fc0007ff
> >vmemmap_vaddr: fdff8000
> >  vmemmap_end: fdff
> >  kimage_text: fc000808
> >   kimage_end: fc000907
> >   kimage_voffset: <-- available if kernel is
> >   not randomized
> >  phys_offset: 40
> >   ...
> >   
> > But it can be read:
> >   
> >   

Re: [Crash-utility] [PATCH v2] arm64: fix kernel memory map handling for kaslr-enabled kernel

[AKASHI Takahiro]

On Tue, May 24, 2016 at 01:59:06PM -0400, Dave Anderson wrote:
> 
> - Original Message -
> > Yet some issues, but ...
> >
> 
> Hi Takahiro,
> 
> Here are my general comments on my testing of the v2 patch, followed 
> by a few comments in the patch itself. 

Thank you for your quick review/testing, again.

> First, the combination of the new memory map layout and KASLR is somewhat
> confusing.  I am testing your patch on a 4.6.0-0.rc7.git2.1.fc25 kernel
> that has this configuration:

Right. I use the "kaslr kernel" or "kaslr-enabled kernel" in two
meanings (almost interchangeably):
   - kernel with a new memory map, that is v4.6 or later
   - kernel that has ability of KASLR (configured with CONFIG_RANDOMIZE_RAM)

When we talked offline, you mentioned the possibility of backporting
KASLR to older kernel, so I hesitated to use "v4.6 or later".
But I think that we'd better use "v4.6 or later" for a clarification
for now.

>   config-arm64:# CONFIG_RANDOMIZE_BASE is not set
> 
> So KASLR doesn't really enter into the picture.  But when bringing
> up the crash session, it shows the "kaslr kernel" WARNING:
> 
>   # ./crash
>   
>   crash 7.1.5++
>   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.
>
>   WARNING: kimage_voffset not identified for kaslr kernel
>   GNU gdb (GDB) 7.6
>   Copyright (C) 2013 Free Software Foundation, Inc.
>   License GPLv3+: GNU GPL version 3 or later 
> 
>   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 "aarch64-unknown-linux-gnu"...
>   
> KERNEL: 
> /usr/lib/debug/lib/modules/4.6.0-0.rc7.git2.1.fc25.aarch64/vmlinux
>   DUMPFILE: /dev/crash
>   CPUS: 8
>   DATE: Tue May 24 10:08:08 2016
> UPTIME: 11 days, 18:32:41
>   LOAD AVERAGE: 0.17, 0.09, 0.12
>  TASKS: 197
>   NODENAME: apm-mustang-ev3-36.khw.lab.eng.bos.redhat.com
>RELEASE: 4.6.0-0.rc7.git2.1.fc25.aarch64
>VERSION: #1 SMP Thu May 12 13:28:43 UTC 2016
>MACHINE: aarch64  (unknown Mhz)
> MEMORY: 16 GB
>PID: 7556
>COMMAND: "crash"
>   TASK: fe00beb45400  [THREAD_INFO: fe00beb98000]
>CPU: 7
>  STATE: TASK_RUNNING (ACTIVE)
>   
>   crash>
>   
> Why show that WARNING in this case?  I understant that it's not 
> stashed during early initialization:

If we don't know kimage_voffset, we can't analyze the contents of
memory (live or kdump).

>   crash> help -m
>  flags: 104000c5 
> (KSYMS_START|VM_L2_64K|VMEMMAP|IRQ_STACKS|MACHDEP_BT_TEXT|NEW_VMEMMAP)
>   ... [ cut ] ...
>memory map layout: new  <--- BTW, this is redundant/not-a-member, 
> and we've got NEW_VMEMMAP
>  VA_BITS: 42
>userspace_top: 0400
>  page_offset: fe00
>   vmalloc_start_addr: fc000800
>  vmalloc_end: fdff5ffe
>modules_vaddr: fc00
>  modules_end: fc0007ff
>vmemmap_vaddr: fdff8000
>  vmemmap_end: fdff
>  kimage_text: fc000808
>   kimage_end: fc000907
>   kimage_voffset: <-- available if kernel is not 
> randomized
>  phys_offset: 40
>   ...
>   
> But it can be read:
>   
>   crash> px kimage_voffset
>   kimage_voffset = $1 = 0xfbc00800
>   crash>
>
> SO because it wasn't determined during session initialization,
> it falls into the "no randomness" section of arm64_VTOP():

Exactly.

>   ulong
>   arm64_VTOP(ulong addr)
>   {
>   if (!(machdep->flags & NEW_VMEMMAP) ||
>   (addr >= machdep->machspec->page_offset)) {
>   return machdep->machspec->phys_offset
>   + (addr - machdep->machspec->page_offset);
>   } else {
>   if (machdep->machspec->kimage_voffset)
>   return addr - machdep->machspec->kimage_voffset;
>   else /* no randomness */
>   return machdep->machspec->phys_offset
>