arm64 pt dumper changes
cover arm64 pt dumper changes
This series updates the kernel page table dumper to:
- not initialize the vmemmap region markers dynamically
- show region boundaries for the kasan shadow region
- include the UEFI runtime services mappings
Ard Biesheuvel (3):
arm64: ptdump: use static initializers for vmemmap region boundaries
arm64: ptdump: add region marker for kasan shadow region
arm64: ptdump: include UEFI runtime service mappings
arch/arm64/mm/dump.c | 58 ++++++++------------ drivers/firmware/efi/arm-runtime.c | 2 +- 2 files changed, 24 insertions(+), 36 deletions(-)
Signature · 1 line
2.5.0
PATCH 1/3 arm64: ptdump: use static initializers for vmemmap region boundaries
There is no need to initialize the vmemmap region boundaries dynamically, since they are compile time constants. So just add these constants to the global struct initializer, and drop the dynamic assignment and related code.
--- arch/arm64/mm/dump.c | 47 +++++--------------- 1 file changed, 12 insertions(+), 35 deletions(-)
arch/arm64/mm/dump.c +12 -35
@@ -34,37 +34,21 @@ struct addr_marker {const char *name; }; -enum address_markers_idx { -MODULES_START_NR =0 , -MODULES_END_NR , -VMALLOC_START_NR , -VMALLOC_END_NR , -#ifdef CONFIG_SPARSEMEM_VMEMMAP -VMEMMAP_START_NR , -VMEMMAP_END_NR , -#endif -FIXADDR_START_NR , -FIXADDR_END_NR , -PCI_START_NR , -PCI_END_NR , -KERNEL_SPACE_NR , -}; -static struct addr_marker address_markers[] = { - {MODULES_VADDR ,"Modules start" }, - {MODULES_END ,"Modules end" }, - {VMALLOC_START ,"vmalloc() Area" }, - {VMALLOC_END ,"vmalloc() End" }, + {MODULES_VADDR ,"Modules start" }, + {MODULES_END ,"Modules end" }, + {VMALLOC_START ,"vmalloc() Area" }, + {VMALLOC_END ,"vmalloc() End" }, #ifdef CONFIG_SPARSEMEM_VMEMMAP - {0 ,"vmemmap start" }, - {0 ,"vmemmap end" }, + { (u64 )vmemmap,"vmemmap start" }, + { (u64 )vmemmap +VMEMMAP_SIZE ,"vmemmap end" }, #endif - {FIXADDR_START ,"Fixmap start" }, - {FIXADDR_TOP ,"Fixmap end" }, - {PCI_IO_START ,"PCI I/O start" }, - {PCI_IO_END ,"PCI I/O end" }, - {PAGE_OFFSET ,"Linear Mapping" }, - {-1 ,NULL }, + {FIXADDR_START ,"Fixmap start" }, + {FIXADDR_TOP ,"Fixmap end" }, + {PCI_IO_START ,"PCI I/O start" }, + {PCI_IO_END ,"PCI I/O end" }, + {PAGE_OFFSET ,"Linear Mapping" }, + {-1 ,NULL }, };/*
@@ -349,13 +333,6 @@ static int ptdump_init(void)for (j =0 ; j < pg_level[i].num; j++) pg_level[i].mask |= pg_level[i].bits[j].mask; -#ifdef CONFIG_SPARSEMEM_VMEMMAP - address_markers[VMEMMAP_START_NR ].start_address = - (unsigned long )virt_to_page (PAGE_OFFSET ); - address_markers[VMEMMAP_END_NR ].start_address = - (unsigned long )virt_to_page (high_memory); -#endif - pe =debugfs_create_file ("kernel_page_tables" ,0400 ,NULL ,NULL , &ptdump_fops);return pe ?0 : -ENOMEM ;
Signature · 1 line
2.5.0
Mark Rutland
reviewerPATCH 1/3 arm64: ptdump: use static initializers for vmemmap region boundaries
Hi,
Quoted 3 lines · Ard Biesheuvel
There is no need to initialize the vmemmap region boundaries dynamically, since they are compile time constants. So just add these constants to the global struct initializer, and drop the dynamic assignment and related code.
This does look nicer.
I believe the intention here was to mark the end of the _populated_ vmemmap region rather than the static VA carveout, so this is a slight change in behaviour.
However, I don't think we gained much by only handling the populated region, and we didn't do the same for the linear map. So FWIW:
Mark.
Quoted 83 lines
Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/mm/dump.c | 47 +++++--------------- 1 file changed, 12 insertions(+), 35 deletions(-)arch/arm64/mm/dump.c +12
-35@@ -34,37 +34,21 @@ struct addr_marker {const char *name; }; -enum address_markers_idx { -MODULES_START_NR =0 , -MODULES_END_NR , -VMALLOC_START_NR , -VMALLOC_END_NR , -#ifdef CONFIG_SPARSEMEM_VMEMMAP -VMEMMAP_START_NR , -VMEMMAP_END_NR , -#endif -FIXADDR_START_NR , -FIXADDR_END_NR , -PCI_START_NR , -PCI_END_NR , -KERNEL_SPACE_NR , -}; -static struct addr_marker address_markers[] = { - {MODULES_VADDR ,"Modules start" }, - {MODULES_END ,"Modules end" }, - {VMALLOC_START ,"vmalloc() Area" }, - {VMALLOC_END ,"vmalloc() End" }, + {MODULES_VADDR ,"Modules start" }, + {MODULES_END ,"Modules end" }, + {VMALLOC_START ,"vmalloc() Area" }, + {VMALLOC_END ,"vmalloc() End" }, #ifdef CONFIG_SPARSEMEM_VMEMMAP - {0 ,"vmemmap start" }, - {0 ,"vmemmap end" }, + { (u64 )vmemmap,"vmemmap start" }, + { (u64 )vmemmap +VMEMMAP_SIZE ,"vmemmap end" }, #endif - {FIXADDR_START ,"Fixmap start" }, - {FIXADDR_TOP ,"Fixmap end" }, - {PCI_IO_START ,"PCI I/O start" }, - {PCI_IO_END ,"PCI I/O end" }, - {PAGE_OFFSET ,"Linear Mapping" }, - {-1 ,NULL }, + {FIXADDR_START ,"Fixmap start" }, + {FIXADDR_TOP ,"Fixmap end" }, + {PCI_IO_START ,"PCI I/O start" }, + {PCI_IO_END ,"PCI I/O end" }, + {PAGE_OFFSET ,"Linear Mapping" }, + {-1 ,NULL }, };/* @@ -349,13 +333,6 @@ static int ptdump_init(void)for (j =0 ; j < pg_level[i].num; j++) pg_level[i].mask |= pg_level[i].bits[j].mask; -#ifdef CONFIG_SPARSEMEM_VMEMMAP - address_markers[VMEMMAP_START_NR ].start_address = - (unsigned long )virt_to_page (PAGE_OFFSET ); - address_markers[VMEMMAP_END_NR ].start_address = - (unsigned long )virt_to_page (high_memory); -#endif - pe =debugfs_create_file ("kernel_page_tables" ,0400 ,NULL ,NULL , &ptdump_fops);return pe ?0 : -ENOMEM ;Signature · 7 lines
2.5.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 1/3 arm64: ptdump: use static initializers for vmemmap region boundaries
Quoted 9 lines · Mark Rutland
Hi,
Quoted 3 lines · Ard Biesheuvel
There is no need to initialize the vmemmap region boundaries dynamically, since they are compile time constants. So just add these constants to the global struct initializer, and drop the dynamic assignment and related code.
This does look nicer.
Quoted 9 lines
I believe the intention here was to mark the end of the _populated_ vmemmap region rather than the static VA carveout, so this is a slight change in behaviour.
However, I don't think we gained much by only handling the populated region, and we didn't do the same for the linear map. So FWIW:
Acked-by Mark Rutland <[email protected]>
Yes, I implemented it off of the existing calculation for printing in init.c which at the time was static. Going the full range does match up better with the rest of the markers.
Quoted 85 lines
Mark.
Quoted 83 lines
Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/mm/dump.c | 47 +++++--------------- 1 file changed, 12 insertions(+), 35 deletions(-)arch/arm64/mm/dump.c +12
-36@@ -34,37 +34,21 @@ struct addr_marker {const char *name; }; -enum address_markers_idx { -MODULES_START_NR =0 , -MODULES_END_NR , -VMALLOC_START_NR , -VMALLOC_END_NR , -#ifdef CONFIG_SPARSEMEM_VMEMMAP -VMEMMAP_START_NR , -VMEMMAP_END_NR , -#endif -FIXADDR_START_NR , -FIXADDR_END_NR , -PCI_START_NR , -PCI_END_NR , -KERNEL_SPACE_NR , -}; -static struct addr_marker address_markers[] = { - {MODULES_VADDR ,"Modules start" }, - {MODULES_END ,"Modules end" }, - {VMALLOC_START ,"vmalloc() Area" }, - {VMALLOC_END ,"vmalloc() End" }, + {MODULES_VADDR ,"Modules start" }, + {MODULES_END ,"Modules end" }, + {VMALLOC_START ,"vmalloc() Area" }, + {VMALLOC_END ,"vmalloc() End" }, #ifdef CONFIG_SPARSEMEM_VMEMMAP - {0 ,"vmemmap start" }, - {0 ,"vmemmap end" }, + { (u64 )vmemmap,"vmemmap start" }, + { (u64 )vmemmap +VMEMMAP_SIZE ,"vmemmap end" }, #endif - {FIXADDR_START ,"Fixmap start" }, - {FIXADDR_TOP ,"Fixmap end" }, - {PCI_IO_START ,"PCI I/O start" }, - {PCI_IO_END ,"PCI I/O end" }, - {PAGE_OFFSET ,"Linear Mapping" }, - {-1 ,NULL }, + {FIXADDR_START ,"Fixmap start" }, + {FIXADDR_TOP ,"Fixmap end" }, + {PCI_IO_START ,"PCI I/O start" }, + {PCI_IO_END ,"PCI I/O end" }, + {PAGE_OFFSET ,"Linear Mapping" }, + {-1 ,NULL }, };/* @@ -349,13 +333,6 @@ static int ptdump_init(void)for (j =0 ; j < pg_level[i].num; j++) pg_level[i].mask |= pg_level[i].bits[j].mask; -#ifdef CONFIG_SPARSEMEM_VMEMMAP - address_markers[VMEMMAP_START_NR ].start_address = - (unsigned long )virt_to_page (PAGE_OFFSET ); - address_markers[VMEMMAP_END_NR ].start_address = - (unsigned long )virt_to_page (high_memory); -#endif - pe =debugfs_create_file ("kernel_page_tables" ,0400 ,NULL ,NULL , &ptdump_fops);return pe ?0 : -ENOMEM ; --2.5.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 2/3 arm64: ptdump: add region marker for kasan shadow region
In reply to Ard BiesheuvelAnnotate the KASAN shadow region with boundary markers, so that its mappings stand out in the page table dumper output.
--- arch/arm64/mm/dump.c | 5 +++++ 1 file changed, 5 insertions(+)
arch/arm64/mm/dump.c +5 -0
@@ -23,6 +23,7 @@#include <linux/seq_file.h> #include <asm/fixmap.h> +#include <asm/kasan.h> #include <asm/memory.h> #include <asm/pgtable.h> #include <asm/pgtable-hwdef.h>
@@ -35,6 +36,10 @@ struct addr_marker { }; static struct addr_marker address_markers[] = { +#ifdef CONFIG_KASAN + { KASAN_SHADOW_START, "Kasan shadow start" }, + { KASAN_SHADOW_END, "Kasan shadow end" }, +#endif { MODULES_VADDR, "Modules start" }, { MODULES_END, "Modules end" }, { VMALLOC_START, "vmalloc() Area" },
Signature · 1 line
2.5.0
Mark Rutland
reviewerPATCH 2/3 arm64: ptdump: add region marker for kasan shadow region
Quoted 4 lines · Ard Biesheuvel
Annotate the KASAN shadow region with boundary markers, so that its mappings stand out in the page table dumper output.
Signed-off-by Ard Biesheuvel <[email protected]>
Mark.
Quoted 36 lines
--- arch/arm64/mm/dump.c | 5 +++++ 1 file changed, 5 insertions(+)arch/arm64/mm/dump.c +5
-0@@ -23,6 +23,7 @@#include <linux/seq_file.h> #include <asm/fixmap.h> +#include <asm/kasan.h> #include <asm/memory.h> #include <asm/pgtable.h> #include <asm/pgtable-hwdef.h> @@ -35,6 +36,10 @@ struct addr_marker { }; static struct addr_marker address_markers[] = { +#ifdef CONFIG_KASAN + { KASAN_SHADOW_START, "Kasan shadow start" }, + { KASAN_SHADOW_END, "Kasan shadow end" }, +#endif { MODULES_VADDR, "Modules start" }, { MODULES_END, "Modules end" }, { VMALLOC_START, "vmalloc() Area" },Signature · 7 lines
2.5.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 3/3 arm64: ptdump: include UEFI runtime service mappings
In reply to Ard BiesheuvelThis adds the UEFI runtime services page table mappings to the output of the kernel page table dumper. These tables are only live during the time UEFI runtime services are being invoked, but we can include them for informational purposes nonetheless.
--- arch/arm64/mm/dump.c | 8 ++++++++ drivers/firmware/efi/arm-runtime.c | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-)
arch/arm64/mm/dump.c +8 -0
@@ -36,6 +36,10 @@ struct addr_marker { }; static struct addr_marker address_markers[] = { +#ifdef CONFIG_EFI + { 0, "UEFI runtime start" }, + { TASK_SIZE_64, "UEFI runtime end" }, +#endif #ifdef CONFIG_KASAN { KASAN_SHADOW_START, "Kasan shadow start" }, { KASAN_SHADOW_END, "Kasan shadow end" },
@@ -310,6 +314,10 @@ static int ptdump_show(struct seq_file *m, void *v) .marker = address_markers, }; +if (IS_ENABLED (CONFIG_EFI )) { +extern struct mm_struct efi_mm; +walk_pgd (&st, &efi_mm,0 ); + }walk_pgd (&st, &init_mm,LOWEST_ADDR );note_page (&st,0 ,0 ,0 );
drivers/firmware/efi/arm-runtime.c +1 -1
@@ -30,7 +30,7 @@extern u64 efi_system_table; -static struct mm_struct efi_mm = { +struct mm_struct efi_mm = { .mm_rb =RB_ROOT , .mm_users =ATOMIC_INIT (2 ), .mm_count =ATOMIC_INIT (1 ),
Signature · 1 line
2.5.0
Mark Rutland
reviewerPATCH 3/3 arm64: ptdump: include UEFI runtime service mappings
Hi,
Quoted 4 lines · Ard Biesheuvel
This adds the UEFI runtime services page table mappings to the output of the kernel page table dumper. These tables are only live during the time UEFI runtime services are being invoked, but we can include them for informational purposes nonetheless.
I would prefer that we had a separate file for the EFI runtime services page tables. As you mention, they are distinct from the kernel and not always live (which is also the case for the idmap, for example).
I have some local patches atop of v4.3 that librify the dumping code and add a separate file for EFI [1]. I spotted a couple other things in doing that (e.g. that we need to pad addresses more).
Is it worth cleaning that up?
Thanks,
Mark.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git arm64/ptdump/librify
Quoted 56 lines
Cc Matt Fleming <[email protected]>Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/mm/dump.c | 8 ++++++++ drivers/firmware/efi/arm-runtime.c | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-)arch/arm64/mm/dump.c +8
-0@@ -36,6 +36,10 @@ struct addr_marker { }; static struct addr_marker address_markers[] = { +#ifdef CONFIG_EFI + { 0, "UEFI runtime start" }, + { TASK_SIZE_64, "UEFI runtime end" }, +#endif #ifdef CONFIG_KASAN { KASAN_SHADOW_START, "Kasan shadow start" }, { KASAN_SHADOW_END, "Kasan shadow end" },@@ -310,6 +314,10 @@ static int ptdump_show(struct seq_file *m, void *v) .marker = address_markers, }; +if (IS_ENABLED (CONFIG_EFI )) { +extern struct mm_struct efi_mm; +walk_pgd (&st, &efi_mm,0 ); + }walk_pgd (&st, &init_mm,LOWEST_ADDR );note_page (&st,0 ,0 ,0 );drivers/firmware/efi/arm-runtime.c +1
-1@@ -30,7 +30,7 @@extern u64 efi_system_table; -static struct mm_struct efi_mm = { +struct mm_struct efi_mm = { .mm_rb =RB_ROOT , .mm_users =ATOMIC_INIT (2 ), .mm_count =ATOMIC_INIT (1 ),Signature · 7 lines
2.5.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel at lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 3/3 arm64: ptdump: include UEFI runtime service mappings
Quoted 12 lines · Mark Rutland
Hi,
Quoted 4 lines · Ard Biesheuvel
This adds the UEFI runtime services page table mappings to the output of the kernel page table dumper. These tables are only live during the time UEFI runtime services are being invoked, but we can include them for informational purposes nonetheless.
I would prefer that we had a separate file for the EFI runtime services page tables. As you mention, they are distinct from the kernel and not always live (which is also the case for the idmap, for example).
Quoted 6 lines
I have some local patches atop of v4.3 that librify the dumping code and add a separate file for EFI [1]. I spotted a couple other things in doing that (e.g. that we need to pad addresses more).
Is it worth cleaning that up?
I think so. It would be especially nice if we could share the registration API between ARM and arm64, since the ptdump code is very similar, and the UEFI range is identical between them
Quoted 56 lines
Quoted 56 lines
Cc Matt Fleming <[email protected]>Signed-off-by Ard Biesheuvel <[email protected]>--- arch/arm64/mm/dump.c | 8 ++++++++ drivers/firmware/efi/arm-runtime.c | 2 +- 2 files changed, 9 insertions(+), 1 deletion(-)arch/arm64/mm/dump.c +8
-0@@ -36,6 +36,10 @@ struct addr_marker { }; static struct addr_marker address_markers[] = { +#ifdef CONFIG_EFI + { 0, "UEFI runtime start" }, + { TASK_SIZE_64, "UEFI runtime end" }, +#endif #ifdef CONFIG_KASAN { KASAN_SHADOW_START, "Kasan shadow start" }, { KASAN_SHADOW_END, "Kasan shadow end" },@@ -310,6 +314,10 @@ static int ptdump_show(struct seq_file *m, void *v) .marker = address_markers, }; +if (IS_ENABLED (CONFIG_EFI )) { +extern struct mm_struct efi_mm; +walk_pgd (&st, &efi_mm,0 ); + }walk_pgd (&st, &init_mm,LOWEST_ADDR );note_page (&st,0 ,0 ,0 );drivers/firmware/efi/arm-runtime.c +1
-2@@ -30,7 +30,7 @@extern u64 efi_system_table; -static struct mm_struct efi_mm = { +struct mm_struct efi_mm = { .mm_rb =RB_ROOT , .mm_users =ATOMIC_INIT (2 ), .mm_count =ATOMIC_INIT (1 ), --2.5.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel at lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
PATCH 3/3 arm64: ptdump: include UEFI runtime service mappings
Quoted 17 lines · Ard Biesheuvel
Quoted 16 lines · Mark Rutland
Hi,
Quoted 4 lines · Ard Biesheuvel
This adds the UEFI runtime services page table mappings to the output of the kernel page table dumper. These tables are only live during the time UEFI runtime services are being invoked, but we can include them for informational purposes nonetheless.
I would prefer that we had a separate file for the EFI runtime services page tables. As you mention, they are distinct from the kernel and not always live (which is also the case for the idmap, for example).
I have some local patches atop of v4.3 that librify the dumping code and add a separate file for EFI [1]. I spotted a couple other things in doing that (e.g. that we need to pad addresses more).
Quoted 6 lines
Quoted 2 lines
Is it worth cleaning that up?
I think so. It would be especially nice if we could share the registration API between ARM and arm64, since the ptdump code is very similar, and the UEFI range is identical between them
In a perfect world, we could unify the ptdump code between x86, arm, and arm64. Doing this is on my TODO list, but way down the list. :P
-Kees
Signature · 2 lines
Kees Cook Chrome OS & Brillo Security
Catalin Marinas
maintainercover arm64 pt dumper changes
In reply to Ard BiesheuvelHi Ard,
Quoted 5 lines · Ard Biesheuvel
This series updates the kernel page table dumper to:
- not initialize the vmemmap region markers dynamically
- show region boundaries for the kasan shadow region
- include the UEFI runtime services mappings
Quoted 8 lines
Ard Biesheuvel (3):
arm64: ptdump: use static initializers for vmemmap region boundaries
arm64: ptdump: add region marker for kasan shadow region
arm64: ptdump: include UEFI runtime service mappingsarch/arm64/mm/dump.c | 58 ++++++++------------ drivers/firmware/efi/arm-runtime.c | 2 +- 2 files changed, 24 insertions(+), 36 deletions(-)
What's the plan with these patches? They no longer apply cleanly on top of arm64 for-next/core.
Signature · 1 line
Catalin
cover arm64 pt dumper changes
Quoted 13 lines · Catalin Marinas
Hi Ard,
Quoted 10 lines · Ard Biesheuvel
This series updates the kernel page table dumper to:
- not initialize the vmemmap region markers dynamically
- show region boundaries for the kasan shadow region
- include the UEFI runtime services mappingsArd Biesheuvel (3):
arm64: ptdump: use static initializers for vmemmap region boundaries
arm64: ptdump: add region marker for kasan shadow region
arm64: ptdump: include UEFI runtime service mappings
Quoted 7 lines
Quoted 3 lines
arch/arm64/mm/dump.c | 58 ++++++++------------ drivers/firmware/efi/arm-runtime.c | 2 +- 2 files changed, 24 insertions(+), 36 deletions(-)What's the plan with these patches? They no longer apply cleanly on top of arm64 for-next/core.
I will respin #1 and #2. Regarding patch #3, I think Mark wanted a more flexible approach?
Mark Rutland
reviewercover arm64 pt dumper changes
Quoted 18 lines · Ard Biesheuvel
Quoted 17 lines · Catalin Marinas
Hi Ard,
Quoted 13 lines · Ard Biesheuvel
This series updates the kernel page table dumper to:
- not initialize the vmemmap region markers dynamically
- show region boundaries for the kasan shadow region
- include the UEFI runtime services mappingsArd Biesheuvel (3):
arm64: ptdump: use static initializers for vmemmap region boundaries
arm64: ptdump: add region marker for kasan shadow region
arm64: ptdump: include UEFI runtime service mappingsarch/arm64/mm/dump.c | 58 ++++++++------------ drivers/firmware/efi/arm-runtime.c | 2 +- 2 files changed, 24 insertions(+), 36 deletions(-)
Quoted 6 lines
Quoted 3 lines
What's the plan with these patches? They no longer apply cleanly on top of arm64 for-next/core.
I will respin #1 and #2. Regarding patch #3, I think Mark wanted a more flexible approach?
My complaint was with placing the EFI table dump in the kernel table dump, as the EFI page tables are distinct, and that VA range is shared by other tables we map from time-to-time, e.g. the idmap.
So I would like to see the EFI tables exposed by a separate file.
I had patches [1] which librify the existing code and do just that, but I haven't had the time to rebase and rework those. If you have the time, feel free to pick that up!
Thanks,
Mark.
[1] https://git.kernel.org/cgit/linux/kernel/git/mark/linux.git/log/?h=arm64/ptdump/librify