[PATCH 0/3] arm64 pt dumper changes

[PATCH 0/3] arm64 pt dumper changes

[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

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(-)

-- 
2.5.0

[PATCH 1/3] arm64: ptdump: use static initializers for vmemmap region boundaries

[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.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm64/mm/dump.c | 47 +++++---------------
 1 file changed, 12 insertions(+), 35 deletions(-)

diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index 6be918478f85..eadcb70e733c 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -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

[PATCH 1/3] arm64: ptdump: use static initializers for vmemmap region boundaries

[Mark Rutland]

Hi,

On Mon, Feb 22, 2016 at 11:00:37AM +0100, Ard Biesheuvel wrote:
> 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:

Acked-by: Mark Rutland <mark.rutland@arm.com>

Mark.

> 
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>  arch/arm64/mm/dump.c | 47 +++++---------------
>  1 file changed, 12 insertions(+), 35 deletions(-)
> 
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index 6be918478f85..eadcb70e733c 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -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 1/3] arm64: ptdump: use static initializers for vmemmap region boundaries

[Laura Abbott]

On 02/22/2016 03:33 AM, Mark Rutland wrote:
> Hi,
>
> On Mon, Feb 22, 2016 at 11:00:37AM +0100, Ard Biesheuvel wrote:
>> 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:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
>

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.

Acked-by: Laura Abbott <labbott@redhat.com>
  
> Mark.
>
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>>   arch/arm64/mm/dump.c | 47 +++++---------------
>>   1 file changed, 12 insertions(+), 35 deletions(-)
>>
>> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
>> index 6be918478f85..eadcb70e733c 100644
>> --- a/arch/arm64/mm/dump.c
>> +++ b/arch/arm64/mm/dump.c
>> @@ -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

[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 <ard.biesheuvel@linaro.org>
---
 arch/arm64/mm/dump.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index eadcb70e733c..12e4b1732303 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -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" },
-- 
2.5.0

[PATCH 2/3] arm64: ptdump: add region marker for kasan shadow region

[Mark Rutland]

On Mon, Feb 22, 2016 at 11:00:38AM +0100, Ard Biesheuvel wrote:
> 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 <ard.biesheuvel@linaro.org>

Acked-by: Mark Rutland <mark.rutland@arm.com>

Mark.

> ---
>  arch/arm64/mm/dump.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index eadcb70e733c..12e4b1732303 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -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" },
> -- 
> 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

[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.

Cc: Matt Fleming <matt@codeblueprint.co.uk>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
 arch/arm64/mm/dump.c               | 8 ++++++++
 drivers/firmware/efi/arm-runtime.c | 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
index 12e4b1732303..e7b937c9ad52 100644
--- a/arch/arm64/mm/dump.c
+++ b/arch/arm64/mm/dump.c
@@ -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);
diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
index 6ae21e41a429..3a3911641049 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -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

[PATCH 3/3] arm64: ptdump: include UEFI runtime service mappings

[Mark Rutland]

Hi,

On Mon, Feb 22, 2016 at 11:00:39AM +0100, Ard Biesheuvel wrote:
> 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

> 
> Cc: Matt Fleming <matt@codeblueprint.co.uk>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
>  arch/arm64/mm/dump.c               | 8 ++++++++
>  drivers/firmware/efi/arm-runtime.c | 2 +-
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
> index 12e4b1732303..e7b937c9ad52 100644
> --- a/arch/arm64/mm/dump.c
> +++ b/arch/arm64/mm/dump.c
> @@ -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);
> diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
> index 6ae21e41a429..3a3911641049 100644
> --- a/drivers/firmware/efi/arm-runtime.c
> +++ b/drivers/firmware/efi/arm-runtime.c
> @@ -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

[Ard Biesheuvel]

On 22 February 2016 at 12:29, Mark Rutland <mark.rutland@arm.com> wrote:
> Hi,
>
> On Mon, Feb 22, 2016 at 11:00:39AM +0100, Ard Biesheuvel wrote:
>> 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?
>

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


>>
>> Cc: Matt Fleming <matt@codeblueprint.co.uk>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>>  arch/arm64/mm/dump.c               | 8 ++++++++
>>  drivers/firmware/efi/arm-runtime.c | 2 +-
>>  2 files changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/mm/dump.c b/arch/arm64/mm/dump.c
>> index 12e4b1732303..e7b937c9ad52 100644
>> --- a/arch/arm64/mm/dump.c
>> +++ b/arch/arm64/mm/dump.c
>> @@ -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);
>> diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c
>> index 6ae21e41a429..3a3911641049 100644
>> --- a/drivers/firmware/efi/arm-runtime.c
>> +++ b/drivers/firmware/efi/arm-runtime.c
>> @@ -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

[Kees Cook]

On Mon, Feb 22, 2016 at 3:51 AM, Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
> On 22 February 2016 at 12:29, Mark Rutland <mark.rutland@arm.com> wrote:
>> Hi,
>>
>> On Mon, Feb 22, 2016 at 11:00:39AM +0100, Ard Biesheuvel wrote:
>>> 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?
>>
>
> 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

-- 
Kees Cook
Chrome OS & Brillo Security

[PATCH 0/3] arm64 pt dumper changes

[Catalin Marinas]

Hi Ard,

On Mon, Feb 22, 2016 at 11:00:36AM +0100, Ard Biesheuvel wrote:
> 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(-)

What's the plan with these patches? They no longer apply cleanly on top
of arm64 for-next/core.

-- 
Catalin

[PATCH 0/3] arm64 pt dumper changes

[Ard Biesheuvel]

On 22 April 2016 at 16:11, Catalin Marinas <catalin.marinas@arm.com> wrote:
> Hi Ard,
>
> On Mon, Feb 22, 2016 at 11:00:36AM +0100, Ard Biesheuvel wrote:
>> 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(-)
>
> 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?

[PATCH 0/3] arm64 pt dumper changes

[Mark Rutland]

On Fri, Apr 22, 2016 at 04:15:03PM +0200, Ard Biesheuvel wrote:
> On 22 April 2016 at 16:11, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > Hi Ard,
> >
> > On Mon, Feb 22, 2016 at 11:00:36AM +0100, Ard Biesheuvel wrote:
> >> 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(-)
> >
> > 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