arm64: fix kernel memory map handling for kaslr-enabled kernel

PATCH Pratyush Anand 3 participants 4 messages May 27, 2016 7 messages not in the archive

Subsystems (2)

Live update kexec handover (KHO)

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): 20160526093955.GA26004@dhcppc6

A message that is not in the archive (sent off-list or not yet received): [email protected]

Pratyush Anand

author

2016-05-27 05:08 UTC #7 lore raw

Quoted 14 lines · AKASHI Takahiro

Quoted 13 lines · Pratyush Anand
Quoted 1 line · AKASHI Takahiro
On Wed, May 25, 2016 at 10:28:10AM -0400, Dave Anderson wrote:
[...]
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
(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?

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
-> 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.

Quoted 7 lines

Quoted 3 lines
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_xxxx macros (if we do not pass vmlinux, like in second kernel). Atsushi, please correct me if I am wrong.

Quoted 9 lines

Quoted 7 lines
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.

Quoted 2 lines

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

Yes, agreed.

Quoted 7 lines

Quoted 3 lines
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.

Quoted 1 line

* 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

Quoted 8 lines

Thanks,
-Takahiro AKASHI
Quoted 4 lines
VMCOREINFO_NUMBER(kimage_voffset);
~Pratyush

Quoted 16 lines

Quoted 7 lines
[1]
https://github.com/pratyushanand/linux/blob/7011e478aae3e568cc8dca15b6c128fe728416f7/arch/arm64/kernel/machine_kexec.c#L275
--
Crash-utility mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/crash-utility
Signature · 7 lines
Thanks,
-Takahiro AKASHI

--
Crash-utility mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/crash-utility

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

AKASHI Takahiro

2016-05-27 06:39 UTC #8 lore raw

Quoted 24 lines · Pratyush Anand

Quoted 14 lines · AKASHI Takahiro
Quoted 13 lines · Pratyush Anand
Quoted 1 line · AKASHI Takahiro
On Wed, May 25, 2016 at 10:28:10AM -0400, Dave Anderson wrote:
[...]
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
(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?
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
-> 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.)

Quoted 8 lines

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?

Quoted 37 lines

Quoted 7 lines
Quoted 3 lines
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_xxxx macros (if we do not pass vmlinux, like in second kernel). Atsushi, please correct me if I am wrong.
Quoted 9 lines
Quoted 7 lines
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.
Quoted 2 lines
As well, pgtable_levels can be determined by va_bits and PAGESIZE. See arch/arm64/Kconfig.
Yes, agreed.
Quoted 7 lines
Quoted 3 lines
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?

Quoted 7 lines

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.

Quoted 8 lines

Quoted 1 line
* 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

Quoted 26 lines

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

--
Crash-utility mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/crash-utility

Signature · 7 lines

Thanks,
-Takahiro AKASHI

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Pratyush Anand

author

2016-05-27 07:29 UTC #9 lore raw

Quoted 37 lines · AKASHI Takahiro

Quoted 24 lines · Pratyush Anand
Quoted 14 lines · AKASHI Takahiro
Quoted 13 lines · Pratyush Anand
Quoted 1 line · AKASHI Takahiro
On Wed, May 25, 2016 at 10:28:10AM -0400, Dave Anderson wrote:
[...]
Quoted 8 lines
Quoted 7 lines
Quoted 2 lines
(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?
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
-> 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.)
Quoted 8 lines
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.

Quoted 6 lines

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.

Quoted 61 lines

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?
Quoted 37 lines
Quoted 7 lines
Quoted 3 lines
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_xxxx macros (if we do not pass vmlinux, like in second kernel). Atsushi, please correct me if I am wrong.
Quoted 9 lines
Quoted 7 lines
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.
Quoted 2 lines
As well, pgtable_levels can be determined by va_bits and PAGESIZE. See arch/arm64/Kconfig.
Yes, agreed.
Quoted 7 lines
Quoted 3 lines
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?
Quoted 7 lines
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.
Quoted 5 lines
Quoted 1 line
* Why do you need CONFIG_KASAN?
KASAN_SHADOW_SIZE is dependent on CONFIG_KASAN.
MODULES_VADDR is dependent on KASAN_SHADOW_SIZE.

Quoted 7 lines

Quoted 3 lines
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. However, instead of passing CONFIG_KASAN and then calculating module, vmalloc and vmemmap areas in makedumpfile, it would be cleaner to pass _text and _end. Then, makedumpfile will be immune to changes in kernel for memory layout of these spaces.

~Pratyush

Quoted 22 lines

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

Quoted 12 lines

Quoted 8 lines
Quoted 8 lines
Signature · 7 lines
Thanks,
-Takahiro AKASHI

--
Crash-utility mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/crash-utility
Signature · 2 lines
Thanks,
-Takahiro AKASHI

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Atsushi Kumagai

2016-05-27 08:22 UTC #10 lore raw

In reply to Pratyush Anand

Hello,

Quoted 21 lines · AKASHI Takahiro

Quoted 20 lines · Pratyush Anand
Quoted 18 lines · AKASHI Takahiro
Quoted 1 line · Dave Anderson
[...]
Quoted 9 lines
Quoted 7 lines
Quoted 2 lines
(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.

Quoted 6 lines

Quoted 2 lines
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.

Quoted 9 lines

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.
Quoted 4 lines
Quoted 3 lines
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.

Quoted 7 lines

Quoted 3 lines
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_xxxx macros (if we do not pass vmlinux, like in second kernel). Atsushi, please correct me if I am wrong.

That's right.

Quoted 25 lines

Quoted 9 lines
Quoted 7 lines
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.
Quoted 2 lines
As well, pgtable_levels can be determined by va_bits and PAGESIZE. See arch/arm64/Kconfig.
Yes, agreed.
Quoted 7 lines
Quoted 3 lines
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?

Quoted 7 lines

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

Quoted 15 lines

Quoted 1 line
* 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
Quoted 4 lines
Thanks,
-Takahiro AKASHI

Quoted 22 lines

Quoted 6 lines
Quoted 6 lines
VMCOREINFO_NUMBER(kimage_voffset);
~Pratyush
[1]
https://github.com/pratyushanand/linux/blob/7011e478aae3e568cc8dca15b6c128fe728416f7/arch/arm64/kernel/machine_kexec
.c#L275
Quoted 14 lines
Quoted 5 lines
--
Crash-utility mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/crash-utility
--
Thanks,
-Takahiro AKASHI
--
Crash-utility mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/crash-utility

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec