[PATCH 0/5] arm64: mte: add core dump support

[PATCH 0/5] arm64: mte: add core dump support

[Catalin Marinas]

Hi,

Add core dump support for MTE tags. When a core file is generated and
the user has mappings with PROT_MTE, segments with the PT_ARM_MEMTAG_MTE
type are dumped. These correspond to the PT_LOAD segments for the same
virtual addresses.

The last patch documents the core file format. The tags are dumped
packed, two tags per byte (unlike ptrace where we have one tag per byte)
and there is no header to define the format, it's all fixed for the
PT_ARM_MEMTAG_MTE type.

Below you can see the output of 'readelf -a core' for a program mapping
two regions with PROT_MTE, one 2-page and the other 4-page long. Half of
the first page in each range was filled with 0xa and 0xb tags
respectively.

Program Headers:
  Type             Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  ...
  LOAD             0x030000 0x0000ffff80034000 0x0000000000000000 0x000000 0x002000 RW  0x1000
  LOAD             0x030000 0x0000ffff80036000 0x0000000000000000 0x004000 0x004000 RW  0x1000
  ...
  LOPROC+0x5441470 0x05b000 0x0000ffff80034000 0x0000000000000000 0x000100 0x002000     0
  LOPROC+0x5441470 0x05b100 0x0000ffff80036000 0x0000000000000000 0x000200 0x004000     0

The relevant 'od -tx1 core' output:

05b000 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
*
05b040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
05b100 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
*
05b140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
05b300

Catalin Marinas (5):
  elfcore: Replace CONFIG_{IA64,UML} checks with a new option
  elf: Introduce the ARM MTE ELF segment type
  arm64: mte: Define the number of bytes for storing the tags in a page
  arm64: mte: Dump the MTE tags in the core file
  arm64: mte: Document the core dump file format

 .../arm64/memory-tagging-extension.rst        |  22 ++++
 arch/arm64/Kconfig                            |   1 +
 arch/arm64/include/asm/mte-def.h              |   1 +
 arch/arm64/kernel/Makefile                    |   1 +
 arch/arm64/kernel/elfcore.c                   | 123 ++++++++++++++++++
 arch/arm64/lib/mte.S                          |   4 +-
 arch/arm64/mm/mteswap.c                       |   2 +-
 arch/ia64/Kconfig                             |   1 +
 arch/x86/um/Kconfig                           |   1 +
 fs/Kconfig.binfmt                             |   3 +
 include/linux/elfcore.h                       |   4 +-
 include/uapi/linux/elf.h                      |   3 +
 12 files changed, 161 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm64/kernel/elfcore.c


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/5] elfcore: Replace CONFIG_{IA64, UML} checks with a new option

[Catalin Marinas]

As arm64 is about to introduce MTE-specific phdrs in the core dump, add
a common CONFIG_ARCH_BINFMT_ELF_EXTRA_PHDRS option currently selectable
by UML_X86 and IA64.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Eric Biederman <ebiederm@xmission.com>
---
 arch/ia64/Kconfig       | 1 +
 arch/x86/um/Kconfig     | 1 +
 fs/Kconfig.binfmt       | 3 +++
 include/linux/elfcore.h | 4 ++--
 4 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 1e33666fa679..4ac4765d7b6b 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -8,6 +8,7 @@ menu "Processor type and features"
 
 config IA64
 	bool
+	select ARCH_BINFMT_ELF_EXTRA_PHDRS
 	select ARCH_HAS_DMA_MARK_CLEAN
 	select ARCH_HAS_STRNCPY_FROM_USER
 	select ARCH_HAS_STRNLEN_USER
diff --git a/arch/x86/um/Kconfig b/arch/x86/um/Kconfig
index 95d26a69088b..21bab4920a92 100644
--- a/arch/x86/um/Kconfig
+++ b/arch/x86/um/Kconfig
@@ -8,6 +8,7 @@ endmenu
 
 config UML_X86
 	def_bool y
+	select ARCH_BINFMT_ELF_EXTRA_PHDRS if X86_32
 	select GENERIC_FIND_FIRST_BIT
 
 config 64BIT
diff --git a/fs/Kconfig.binfmt b/fs/Kconfig.binfmt
index 4d5ae61580aa..68e586283764 100644
--- a/fs/Kconfig.binfmt
+++ b/fs/Kconfig.binfmt
@@ -36,6 +36,9 @@ config COMPAT_BINFMT_ELF
 config ARCH_BINFMT_ELF_STATE
 	bool
 
+config ARCH_BINFMT_ELF_EXTRA_PHDRS
+	bool
+
 config ARCH_HAVE_ELF_PROT
 	bool
 
diff --git a/include/linux/elfcore.h b/include/linux/elfcore.h
index 957ebec35aad..ab49f2567c8c 100644
--- a/include/linux/elfcore.h
+++ b/include/linux/elfcore.h
@@ -109,7 +109,7 @@ static inline int elf_core_copy_task_fpregs(struct task_struct *t, struct pt_reg
 #endif
 }
 
-#if (defined(CONFIG_UML) && defined(CONFIG_X86_32)) || defined(CONFIG_IA64)
+#ifdef CONFIG_ARCH_BINFMT_ELF_EXTRA_PHDRS
 /*
  * These functions parameterize elf_core_dump in fs/binfmt_elf.c to write out
  * extra segments containing the gate DSO contents.  Dumping its
@@ -144,6 +144,6 @@ static inline size_t elf_core_extra_data_size(void)
 {
 	return 0;
 }
-#endif
+#endif /* CONFIG_ARCH_EXTRA_PHDRS */
 
 #endif /* _LINUX_ELFCORE_H */

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/5] elf: Introduce the ARM MTE ELF segment type

[Catalin Marinas]

Memory tags will be dumped in the core file as segments with their own
type. Discussions with the binutils and the generic ABI community
settled on using new definitions in the PT_*PROC space (and to be
documented in the processor-specific ABIs).

Introduce PT_ARM_MEMTAG_MTE as (PT_LOPROC + 0x1). Not included in this
patch since there is no upstream support but the CHERI/BSD community
will also reserve:

  #define PT_ARM_MEMTAG_CHERI    (PT_LOPROC + 0x2)
  #define PT_RISCV_MEMTAG_CHERI  (PT_LOPROC + 0x3)

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
 include/uapi/linux/elf.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index 61bf4774b8f2..fe8e5b74cb39 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h
@@ -40,6 +40,9 @@ typedef __s64	Elf64_Sxword;
 
 #define PT_GNU_STACK	(PT_LOOS + 0x474e551)
 
+/* ARM MTE memory tag segment type */
+#define PT_ARM_MEMTAG_MTE	(PT_LOPROC + 0x1)
+
 /*
  * Extended Numbering
  *

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/5] elf: Introduce the ARM MTE ELF segment type

[Luis Machado]

On 12/8/21 9:19 AM, Catalin Marinas wrote:
> Memory tags will be dumped in the core file as segments with their own
> type. Discussions with the binutils and the generic ABI community
> settled on using new definitions in the PT_*PROC space (and to be
> documented in the processor-specific ABIs).
> 
> Introduce PT_ARM_MEMTAG_MTE as (PT_LOPROC + 0x1). Not included in this
> patch since there is no upstream support but the CHERI/BSD community
> will also reserve:
> 
>    #define PT_ARM_MEMTAG_CHERI    (PT_LOPROC + 0x2)
>    #define PT_RISCV_MEMTAG_CHERI  (PT_LOPROC + 0x3)
> 
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
>   include/uapi/linux/elf.h | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
> index 61bf4774b8f2..fe8e5b74cb39 100644
> --- a/include/uapi/linux/elf.h
> +++ b/include/uapi/linux/elf.h
> @@ -40,6 +40,9 @@ typedef __s64	Elf64_Sxword;
>   
>   #define PT_GNU_STACK	(PT_LOOS + 0x474e551)
>   
> +/* ARM MTE memory tag segment type */
> +#define PT_ARM_MEMTAG_MTE	(PT_LOPROC + 0x1)
> +
>   /*
>    * Extended Numbering
>    *
> 

Sorry for the delay. This looks good from the debugger's side.

Acked-by: Luis Machado <luis.machado@linaro.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/5] arm64: mte: Define the number of bytes for storing the tags in a page

[Catalin Marinas]

Rather than explicitly calculating the number of bytes for a compact tag
storage format corresponding to a page, just add a MTE_PAGE_TAG_STORAGE
macro. With the current MTE implementation of 4 bits per tag, we store
2 tags in a byte.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm64/include/asm/mte-def.h | 1 +
 arch/arm64/lib/mte.S             | 4 ++--
 arch/arm64/mm/mteswap.c          | 2 +-
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/mte-def.h b/arch/arm64/include/asm/mte-def.h
index 626d359b396e..14ee86b019c2 100644
--- a/arch/arm64/include/asm/mte-def.h
+++ b/arch/arm64/include/asm/mte-def.h
@@ -11,6 +11,7 @@
 #define MTE_TAG_SHIFT		56
 #define MTE_TAG_SIZE		4
 #define MTE_TAG_MASK		GENMASK((MTE_TAG_SHIFT + (MTE_TAG_SIZE - 1)), MTE_TAG_SHIFT)
+#define MTE_PAGE_TAG_STORAGE	(MTE_GRANULES_PER_PAGE * MTE_TAG_SIZE / 8)
 
 #define __MTE_PREAMBLE		ARM64_ASM_PREAMBLE ".arch_extension memtag\n"
 
diff --git a/arch/arm64/lib/mte.S b/arch/arm64/lib/mte.S
index e83643b3995f..62a1025aa118 100644
--- a/arch/arm64/lib/mte.S
+++ b/arch/arm64/lib/mte.S
@@ -128,7 +128,7 @@ SYM_FUNC_END(mte_copy_tags_to_user)
 /*
  * Save the tags in a page
  *   x0 - page address
- *   x1 - tag storage
+ *   x1 - tag storage, MTE_PAGE_TAG_STORAGE bytes
  */
 SYM_FUNC_START(mte_save_page_tags)
 	multitag_transfer_size x7, x5
@@ -152,7 +152,7 @@ SYM_FUNC_END(mte_save_page_tags)
 /*
  * Restore the tags in a page
  *   x0 - page address
- *   x1 - tag storage
+ *   x1 - tag storage, MTE_PAGE_TAG_STORAGE bytes
  */
 SYM_FUNC_START(mte_restore_page_tags)
 	multitag_transfer_size x7, x5
diff --git a/arch/arm64/mm/mteswap.c b/arch/arm64/mm/mteswap.c
index 7c4ef56265ee..a9e50e930484 100644
--- a/arch/arm64/mm/mteswap.c
+++ b/arch/arm64/mm/mteswap.c
@@ -12,7 +12,7 @@ static DEFINE_XARRAY(mte_pages);
 void *mte_allocate_tag_storage(void)
 {
 	/* tags granule is 16 bytes, 2 tags stored per byte */
-	return kmalloc(PAGE_SIZE / 16 / 2, GFP_KERNEL);
+	return kmalloc(MTE_PAGE_TAG_STORAGE, GFP_KERNEL);
 }
 
 void mte_free_tag_storage(char *storage)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/5] arm64: mte: Define the number of bytes for storing the tags in a page

[Luis Machado]

On 12/8/21 9:19 AM, Catalin Marinas wrote:
> Rather than explicitly calculating the number of bytes for a compact tag
> storage format corresponding to a page, just add a MTE_PAGE_TAG_STORAGE
> macro. With the current MTE implementation of 4 bits per tag, we store
> 2 tags in a byte.
> 
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
>   arch/arm64/include/asm/mte-def.h | 1 +
>   arch/arm64/lib/mte.S             | 4 ++--
>   arch/arm64/mm/mteswap.c          | 2 +-
>   3 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/mte-def.h b/arch/arm64/include/asm/mte-def.h
> index 626d359b396e..14ee86b019c2 100644
> --- a/arch/arm64/include/asm/mte-def.h
> +++ b/arch/arm64/include/asm/mte-def.h
> @@ -11,6 +11,7 @@
>   #define MTE_TAG_SHIFT		56
>   #define MTE_TAG_SIZE		4
>   #define MTE_TAG_MASK		GENMASK((MTE_TAG_SHIFT + (MTE_TAG_SIZE - 1)), MTE_TAG_SHIFT)
> +#define MTE_PAGE_TAG_STORAGE	(MTE_GRANULES_PER_PAGE * MTE_TAG_SIZE / 8)
>   
>   #define __MTE_PREAMBLE		ARM64_ASM_PREAMBLE ".arch_extension memtag\n"
>   
> diff --git a/arch/arm64/lib/mte.S b/arch/arm64/lib/mte.S
> index e83643b3995f..62a1025aa118 100644
> --- a/arch/arm64/lib/mte.S
> +++ b/arch/arm64/lib/mte.S
> @@ -128,7 +128,7 @@ SYM_FUNC_END(mte_copy_tags_to_user)
>   /*
>    * Save the tags in a page
>    *   x0 - page address
> - *   x1 - tag storage
> + *   x1 - tag storage, MTE_PAGE_TAG_STORAGE bytes
>    */
>   SYM_FUNC_START(mte_save_page_tags)
>   	multitag_transfer_size x7, x5
> @@ -152,7 +152,7 @@ SYM_FUNC_END(mte_save_page_tags)
>   /*
>    * Restore the tags in a page
>    *   x0 - page address
> - *   x1 - tag storage
> + *   x1 - tag storage, MTE_PAGE_TAG_STORAGE bytes
>    */
>   SYM_FUNC_START(mte_restore_page_tags)
>   	multitag_transfer_size x7, x5
> diff --git a/arch/arm64/mm/mteswap.c b/arch/arm64/mm/mteswap.c
> index 7c4ef56265ee..a9e50e930484 100644
> --- a/arch/arm64/mm/mteswap.c
> +++ b/arch/arm64/mm/mteswap.c
> @@ -12,7 +12,7 @@ static DEFINE_XARRAY(mte_pages);
>   void *mte_allocate_tag_storage(void)
>   {
>   	/* tags granule is 16 bytes, 2 tags stored per byte */
> -	return kmalloc(PAGE_SIZE / 16 / 2, GFP_KERNEL);
> +	return kmalloc(MTE_PAGE_TAG_STORAGE, GFP_KERNEL);
>   }
>   
>   void mte_free_tag_storage(char *storage)
> 

Acked-by: Luis Machado <luis.machado@linaro.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 4/5] arm64: mte: Dump the MTE tags in the core file

[Catalin Marinas]

For each vma mapped with PROT_MTE (the VM_MTE flag set), generate a
PT_ARM_MEMTAG_MTE segment in the core file and dump the corresponding
tags. The in-file size for such segments is 128 bytes per page.

For pages in a VM_MTE vma which are not present in the user page tables
or don't have the PG_mte_tagged flag set (e.g. execute-only), just write
zeros in the core file.

An example of program headers for two vmas, one 2-page, the other 4-page
long:

  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  ...
  LOAD           0x030000 0x0000ffff80034000 0x0000000000000000 0x000000 0x002000 RW  0x1000
  LOAD           0x030000 0x0000ffff80036000 0x0000000000000000 0x004000 0x004000 RW  0x1000
  ...
  LOPROC+0x1     0x05b000 0x0000ffff80034000 0x0000000000000000 0x000100 0x002000     0
  LOPROC+0x1     0x05b100 0x0000ffff80036000 0x0000000000000000 0x000200 0x004000     0

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
 arch/arm64/Kconfig          |   1 +
 arch/arm64/kernel/Makefile  |   1 +
 arch/arm64/kernel/elfcore.c | 123 ++++++++++++++++++++++++++++++++++++
 3 files changed, 125 insertions(+)
 create mode 100644 arch/arm64/kernel/elfcore.c

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index c4207cf9bb17..fe5d72dd5a3b 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -10,6 +10,7 @@ config ARM64
 	select ACPI_SPCR_TABLE if ACPI
 	select ACPI_PPTT if ACPI
 	select ARCH_HAS_DEBUG_WX
+	select ARCH_BINFMT_ELF_EXTRA_PHDRS
 	select ARCH_BINFMT_ELF_STATE
 	select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
 	select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 88b3e2a21408..986837d7ec82 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_ARM64_ACPI_PARKING_PROTOCOL)	+= acpi_parking_protocol.o
 obj-$(CONFIG_PARAVIRT)			+= paravirt.o
 obj-$(CONFIG_RANDOMIZE_BASE)		+= kaslr.o
 obj-$(CONFIG_HIBERNATION)		+= hibernate.o hibernate-asm.o
+obj-$(CONFIG_ELF_CORE)			+= elfcore.o
 obj-$(CONFIG_KEXEC_CORE)		+= machine_kexec.o relocate_kernel.o	\
 					   cpu-reset.o
 obj-$(CONFIG_KEXEC_FILE)		+= machine_kexec_file.o kexec_image.o
diff --git a/arch/arm64/kernel/elfcore.c b/arch/arm64/kernel/elfcore.c
new file mode 100644
index 000000000000..3455ee4acc04
--- /dev/null
+++ b/arch/arm64/kernel/elfcore.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/coredump.h>
+#include <linux/elfcore.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+
+#include <asm/cpufeature.h>
+#include <asm/mte.h>
+
+#define for_each_mte_vma(tsk, vma)					\
+	if (system_supports_mte())					\
+		for (vma = tsk->mm->mmap; vma; vma = vma->vm_next)	\
+			if (vma->vm_flags & VM_MTE)
+
+static unsigned long mte_vma_tag_dump_size(struct vm_area_struct *vma)
+{
+	if (vma->vm_flags & VM_DONTDUMP)
+		return 0;
+
+	return vma_pages(vma) * MTE_PAGE_TAG_STORAGE;
+}
+
+/* Derived from dump_user_range(); start/end must be page-aligned */
+static int mte_dump_tag_range(struct coredump_params *cprm,
+			      unsigned long start, unsigned long end)
+{
+	unsigned long addr;
+
+	for (addr = start; addr < end; addr += PAGE_SIZE) {
+		char tags[MTE_PAGE_TAG_STORAGE];
+		struct page *page = get_dump_page(addr);
+
+		/*
+		 * get_dump_page() returns NULL when encountering an empty
+		 * page table entry that would otherwise have been filled with
+		 * the zero page. Skip the equivalent tag dump which would
+		 * have been all zeros.
+		 */
+		if (!page) {
+			dump_skip(cprm, MTE_PAGE_TAG_STORAGE);
+			continue;
+		}
+
+		/*
+		 * Pages mapped in user space as !pte_access_permitted() (e.g.
+		 * PROT_EXEC only) may not have the PG_mte_tagged flag set.
+		 */
+		if (!test_bit(PG_mte_tagged, &page->flags)) {
+			put_page(page);
+			dump_skip(cprm, MTE_PAGE_TAG_STORAGE);
+			continue;
+		}
+
+		mte_save_page_tags(page_address(page), tags);
+		put_page(page);
+		if (!dump_emit(cprm, tags, MTE_PAGE_TAG_STORAGE))
+			return 0;
+	}
+
+	return 1;
+}
+
+Elf_Half elf_core_extra_phdrs(void)
+{
+	struct vm_area_struct *vma;
+	int vma_count = 0;
+
+	for_each_mte_vma(current, vma)
+		vma_count++;
+
+	return vma_count;
+}
+
+int elf_core_write_extra_phdrs(struct coredump_params *cprm, loff_t offset)
+{
+	struct vm_area_struct *vma;
+
+	for_each_mte_vma(current, vma) {
+		struct elf_phdr phdr;
+
+		phdr.p_type = PT_ARM_MEMTAG_MTE;
+		phdr.p_offset = offset;
+		phdr.p_vaddr = vma->vm_start;
+		phdr.p_paddr = 0;
+		phdr.p_filesz = mte_vma_tag_dump_size(vma);
+		phdr.p_memsz = vma->vm_end - vma->vm_start;
+		offset += phdr.p_filesz;
+		phdr.p_flags = 0;
+		phdr.p_align = 0;
+
+		if (!dump_emit(cprm, &phdr, sizeof(phdr)))
+			return 0;
+	}
+
+	return 1;
+}
+
+size_t elf_core_extra_data_size(void)
+{
+	struct vm_area_struct *vma;
+	size_t data_size = 0;
+
+	for_each_mte_vma(current, vma)
+		data_size += mte_vma_tag_dump_size(vma);
+
+	return data_size;
+}
+
+int elf_core_write_extra_data(struct coredump_params *cprm)
+{
+	struct vm_area_struct *vma;
+
+	for_each_mte_vma(current, vma) {
+		if (vma->vm_flags & VM_DONTDUMP)
+			continue;
+
+		if (!mte_dump_tag_range(cprm, vma->vm_start, vma->vm_end))
+			return 0;
+	}
+
+	return 1;
+}

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 4/5] arm64: mte: Dump the MTE tags in the core file

[Luis Machado]

On 12/8/21 9:19 AM, Catalin Marinas wrote:
> For each vma mapped with PROT_MTE (the VM_MTE flag set), generate a
> PT_ARM_MEMTAG_MTE segment in the core file and dump the corresponding
> tags. The in-file size for such segments is 128 bytes per page.
> 
> For pages in a VM_MTE vma which are not present in the user page tables
> or don't have the PG_mte_tagged flag set (e.g. execute-only), just write
> zeros in the core file.
> 
> An example of program headers for two vmas, one 2-page, the other 4-page
> long:
> 
>    Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
>    ...
>    LOAD           0x030000 0x0000ffff80034000 0x0000000000000000 0x000000 0x002000 RW  0x1000
>    LOAD           0x030000 0x0000ffff80036000 0x0000000000000000 0x004000 0x004000 RW  0x1000
>    ...
>    LOPROC+0x1     0x05b000 0x0000ffff80034000 0x0000000000000000 0x000100 0x002000     0
>    LOPROC+0x1     0x05b100 0x0000ffff80036000 0x0000000000000000 0x000200 0x004000     0
> 
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
>   arch/arm64/Kconfig          |   1 +
>   arch/arm64/kernel/Makefile  |   1 +
>   arch/arm64/kernel/elfcore.c | 123 ++++++++++++++++++++++++++++++++++++
>   3 files changed, 125 insertions(+)
>   create mode 100644 arch/arm64/kernel/elfcore.c
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index c4207cf9bb17..fe5d72dd5a3b 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -10,6 +10,7 @@ config ARM64
>   	select ACPI_SPCR_TABLE if ACPI
>   	select ACPI_PPTT if ACPI
>   	select ARCH_HAS_DEBUG_WX
> +	select ARCH_BINFMT_ELF_EXTRA_PHDRS
>   	select ARCH_BINFMT_ELF_STATE
>   	select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
>   	select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION
> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> index 88b3e2a21408..986837d7ec82 100644
> --- a/arch/arm64/kernel/Makefile
> +++ b/arch/arm64/kernel/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_ARM64_ACPI_PARKING_PROTOCOL)	+= acpi_parking_protocol.o
>   obj-$(CONFIG_PARAVIRT)			+= paravirt.o
>   obj-$(CONFIG_RANDOMIZE_BASE)		+= kaslr.o
>   obj-$(CONFIG_HIBERNATION)		+= hibernate.o hibernate-asm.o
> +obj-$(CONFIG_ELF_CORE)			+= elfcore.o
>   obj-$(CONFIG_KEXEC_CORE)		+= machine_kexec.o relocate_kernel.o	\
>   					   cpu-reset.o
>   obj-$(CONFIG_KEXEC_FILE)		+= machine_kexec_file.o kexec_image.o
> diff --git a/arch/arm64/kernel/elfcore.c b/arch/arm64/kernel/elfcore.c
> new file mode 100644
> index 000000000000..3455ee4acc04
> --- /dev/null
> +++ b/arch/arm64/kernel/elfcore.c
> @@ -0,0 +1,123 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include <linux/coredump.h>
> +#include <linux/elfcore.h>
> +#include <linux/kernel.h>
> +#include <linux/mm.h>
> +
> +#include <asm/cpufeature.h>
> +#include <asm/mte.h>
> +
> +#define for_each_mte_vma(tsk, vma)					\
> +	if (system_supports_mte())					\
> +		for (vma = tsk->mm->mmap; vma; vma = vma->vm_next)	\
> +			if (vma->vm_flags & VM_MTE)
> +
> +static unsigned long mte_vma_tag_dump_size(struct vm_area_struct *vma)
> +{
> +	if (vma->vm_flags & VM_DONTDUMP)
> +		return 0;
> +
> +	return vma_pages(vma) * MTE_PAGE_TAG_STORAGE;
> +}
> +
> +/* Derived from dump_user_range(); start/end must be page-aligned */
> +static int mte_dump_tag_range(struct coredump_params *cprm,
> +			      unsigned long start, unsigned long end)
> +{
> +	unsigned long addr;
> +
> +	for (addr = start; addr < end; addr += PAGE_SIZE) {
> +		char tags[MTE_PAGE_TAG_STORAGE];
> +		struct page *page = get_dump_page(addr);
> +
> +		/*
> +		 * get_dump_page() returns NULL when encountering an empty
> +		 * page table entry that would otherwise have been filled with
> +		 * the zero page. Skip the equivalent tag dump which would
> +		 * have been all zeros.
> +		 */
> +		if (!page) {
> +			dump_skip(cprm, MTE_PAGE_TAG_STORAGE);
> +			continue;
> +		}
> +
> +		/*
> +		 * Pages mapped in user space as !pte_access_permitted() (e.g.
> +		 * PROT_EXEC only) may not have the PG_mte_tagged flag set.
> +		 */
> +		if (!test_bit(PG_mte_tagged, &page->flags)) {
> +			put_page(page);
> +			dump_skip(cprm, MTE_PAGE_TAG_STORAGE);
> +			continue;
> +		}
> +
> +		mte_save_page_tags(page_address(page), tags);
> +		put_page(page);
> +		if (!dump_emit(cprm, tags, MTE_PAGE_TAG_STORAGE))
> +			return 0;
> +	}
> +
> +	return 1;
> +}
> +
> +Elf_Half elf_core_extra_phdrs(void)
> +{
> +	struct vm_area_struct *vma;
> +	int vma_count = 0;
> +
> +	for_each_mte_vma(current, vma)
> +		vma_count++;
> +
> +	return vma_count;
> +}
> +
> +int elf_core_write_extra_phdrs(struct coredump_params *cprm, loff_t offset)
> +{
> +	struct vm_area_struct *vma;
> +
> +	for_each_mte_vma(current, vma) {
> +		struct elf_phdr phdr;
> +
> +		phdr.p_type = PT_ARM_MEMTAG_MTE;
> +		phdr.p_offset = offset;
> +		phdr.p_vaddr = vma->vm_start;
> +		phdr.p_paddr = 0;
> +		phdr.p_filesz = mte_vma_tag_dump_size(vma);
> +		phdr.p_memsz = vma->vm_end - vma->vm_start;
> +		offset += phdr.p_filesz;
> +		phdr.p_flags = 0;
> +		phdr.p_align = 0;
> +
> +		if (!dump_emit(cprm, &phdr, sizeof(phdr)))
> +			return 0;
> +	}
> +
> +	return 1;
> +}
> +
> +size_t elf_core_extra_data_size(void)
> +{
> +	struct vm_area_struct *vma;
> +	size_t data_size = 0;
> +
> +	for_each_mte_vma(current, vma)
> +		data_size += mte_vma_tag_dump_size(vma);
> +
> +	return data_size;
> +}
> +
> +int elf_core_write_extra_data(struct coredump_params *cprm)
> +{
> +	struct vm_area_struct *vma;
> +
> +	for_each_mte_vma(current, vma) {
> +		if (vma->vm_flags & VM_DONTDUMP)
> +			continue;
> +
> +		if (!mte_dump_tag_range(cprm, vma->vm_start, vma->vm_end))
> +			return 0;
> +	}
> +
> +	return 1;
> +}
> 

Acked-by: Luis Machado <luis.machado@linaro.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 5/5] arm64: mte: Document the core dump file format

[Catalin Marinas]

Add the program header definition and data layout for the
PT_ARM_MEMTAG_MTE segments.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
 .../arm64/memory-tagging-extension.rst        | 22 +++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/Documentation/arm64/memory-tagging-extension.rst b/Documentation/arm64/memory-tagging-extension.rst
index 7b99c8f428eb..34c7eb47f61e 100644
--- a/Documentation/arm64/memory-tagging-extension.rst
+++ b/Documentation/arm64/memory-tagging-extension.rst
@@ -213,6 +213,28 @@ address ABI control and MTE configuration of a process as per the
 Documentation/arm64/tagged-address-abi.rst and above. The corresponding
 ``regset`` is 1 element of 8 bytes (``sizeof(long))``).
 
+Core dump support
+-----------------
+
+The allocation tags for user memory mapped with ``PROT_MTE`` are dumped
+in the core file as additional ``PT_ARM_MEMTAG_MTE`` segments. The
+program header for such segment is defined as:
+
+:``p_type``: ``PT_ARM_MEMTAG_MTE``
+:``p_flags``: 0
+:``p_offset``: segment file offset
+:``p_vaddr``: segment virtual address, same as the corresponding
+  ``PT_LOAD`` segment
+:``p_paddr``: 0
+:``p_filesz``: segment size in file, calculated as ``p_mem_sz / 16 / 2``
+:``p_memsz``: segment size in memory, same as the corresponding
+  ``PT_LOAD`` segment
+:``p_align``: 0
+
+The tags are stored in the core file at ``p_offset`` as two 4-bit tags
+in a byte. With the tag granule of 16 bytes, a 4K page requires 128
+bytes in the core file.
+
 Example of correct usage
 ========================
 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 5/5] arm64: mte: Document the core dump file format

[Luis Machado]

On 12/8/21 9:19 AM, Catalin Marinas wrote:
> Add the program header definition and data layout for the
> PT_ARM_MEMTAG_MTE segments.
> 
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
>   .../arm64/memory-tagging-extension.rst        | 22 +++++++++++++++++++
>   1 file changed, 22 insertions(+)
> 
> diff --git a/Documentation/arm64/memory-tagging-extension.rst b/Documentation/arm64/memory-tagging-extension.rst
> index 7b99c8f428eb..34c7eb47f61e 100644
> --- a/Documentation/arm64/memory-tagging-extension.rst
> +++ b/Documentation/arm64/memory-tagging-extension.rst
> @@ -213,6 +213,28 @@ address ABI control and MTE configuration of a process as per the
>   Documentation/arm64/tagged-address-abi.rst and above. The corresponding
>   ``regset`` is 1 element of 8 bytes (``sizeof(long))``).
>   
> +Core dump support
> +-----------------
> +
> +The allocation tags for user memory mapped with ``PROT_MTE`` are dumped
> +in the core file as additional ``PT_ARM_MEMTAG_MTE`` segments. The
> +program header for such segment is defined as:
> +
> +:``p_type``: ``PT_ARM_MEMTAG_MTE``
> +:``p_flags``: 0
> +:``p_offset``: segment file offset
> +:``p_vaddr``: segment virtual address, same as the corresponding
> +  ``PT_LOAD`` segment
> +:``p_paddr``: 0
> +:``p_filesz``: segment size in file, calculated as ``p_mem_sz / 16 / 2``

For the sake of making things extra clear, I'd describe what the 
constants (16 and 2) mean.

> +:``p_memsz``: segment size in memory, same as the corresponding
> +  ``PT_LOAD`` segment
> +:``p_align``: 0
> +
> +The tags are stored in the core file at ``p_offset`` as two 4-bit tags
> +in a byte. With the tag granule of 16 bytes, a 4K page requires 128
> +bytes in the core file.
> +
>   Example of correct usage
>   ========================
>   
> 

Otherwise looks good to me.

Acked-by: Luis Machado <luis.machado@linaro.org>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 5/5] arm64: mte: Document the core dump file format

[Catalin Marinas]

Hi Luis,

On Mon, Jan 03, 2022 at 02:27:54PM -0300, Luis Machado wrote:
> On 12/8/21 9:19 AM, Catalin Marinas wrote:
> > diff --git a/Documentation/arm64/memory-tagging-extension.rst b/Documentation/arm64/memory-tagging-extension.rst
> > index 7b99c8f428eb..34c7eb47f61e 100644
> > --- a/Documentation/arm64/memory-tagging-extension.rst
> > +++ b/Documentation/arm64/memory-tagging-extension.rst
> > @@ -213,6 +213,28 @@ address ABI control and MTE configuration of a process as per the
> >   Documentation/arm64/tagged-address-abi.rst and above. The corresponding
> >   ``regset`` is 1 element of 8 bytes (``sizeof(long))``).
> > +Core dump support
> > +-----------------
> > +
> > +The allocation tags for user memory mapped with ``PROT_MTE`` are dumped
> > +in the core file as additional ``PT_ARM_MEMTAG_MTE`` segments. The
> > +program header for such segment is defined as:
> > +
> > +:``p_type``: ``PT_ARM_MEMTAG_MTE``
> > +:``p_flags``: 0
> > +:``p_offset``: segment file offset
> > +:``p_vaddr``: segment virtual address, same as the corresponding
> > +  ``PT_LOAD`` segment
> > +:``p_paddr``: 0
> > +:``p_filesz``: segment size in file, calculated as ``p_mem_sz / 16 / 2``
> 
> For the sake of making things extra clear, I'd describe what the constants
> (16 and 2) mean.

I'll rewrite this as: "``p_mem_sz / 32`` (two 4-bit tags cover 32 bytes
of memory)". I find the "16 / 2" more confusing.

> Acked-by: Luis Machado <luis.machado@linaro.org>

Thanks for the acks.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/5] arm64: mte: add core dump support

[Eric W. Biederman]

Catalin Marinas <catalin.marinas@arm.com> writes:

> Hi,
>
> Add core dump support for MTE tags. When a core file is generated and
> the user has mappings with PROT_MTE, segments with the PT_ARM_MEMTAG_MTE
> type are dumped. These correspond to the PT_LOAD segments for the same
> virtual addresses.

Why did you choose to encode this information as a program header
instead of as a note?

I can't see anything fundamentally wrong with encoding this information
as a new program header type, but I also don't know what makes this
information special enough that it doesn't work as a note.

The advantage for encoding things as a note is that everyone pretty much
already knows what to do with notes, and notes they do not understand.

If this was something the loader would need when loading an application,
and the loader could parse this program header as well that would
definitely be justification for using a program header.

I also don't know what an MTE tag is.  A memory type extension?

Eric


> The last patch documents the core file format. The tags are dumped
> packed, two tags per byte (unlike ptrace where we have one tag per byte)
> and there is no header to define the format, it's all fixed for the
> PT_ARM_MEMTAG_MTE type.
>
> Below you can see the output of 'readelf -a core' for a program mapping
> two regions with PROT_MTE, one 2-page and the other 4-page long. Half of
> the first page in each range was filled with 0xa and 0xb tags
> respectively.
>
> Program Headers:
>   Type             Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
>   ...
>   LOAD             0x030000 0x0000ffff80034000 0x0000000000000000 0x000000 0x002000 RW  0x1000
>   LOAD             0x030000 0x0000ffff80036000 0x0000000000000000 0x004000 0x004000 RW  0x1000
>   ...
>   LOPROC+0x5441470 0x05b000 0x0000ffff80034000 0x0000000000000000 0x000100 0x002000     0
>   LOPROC+0x5441470 0x05b100 0x0000ffff80036000 0x0000000000000000 0x000200 0x004000     0
>
> The relevant 'od -tx1 core' output:
>
> 05b000 bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb bb
> *
> 05b040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *
> 05b100 aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa aa
> *
> 05b140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> *
> 05b300
>
> Catalin Marinas (5):
>   elfcore: Replace CONFIG_{IA64,UML} checks with a new option
>   elf: Introduce the ARM MTE ELF segment type
>   arm64: mte: Define the number of bytes for storing the tags in a page
>   arm64: mte: Dump the MTE tags in the core file
>   arm64: mte: Document the core dump file format
>
>  .../arm64/memory-tagging-extension.rst        |  22 ++++
>  arch/arm64/Kconfig                            |   1 +
>  arch/arm64/include/asm/mte-def.h              |   1 +
>  arch/arm64/kernel/Makefile                    |   1 +
>  arch/arm64/kernel/elfcore.c                   | 123 ++++++++++++++++++
>  arch/arm64/lib/mte.S                          |   4 +-
>  arch/arm64/mm/mteswap.c                       |   2 +-
>  arch/ia64/Kconfig                             |   1 +
>  arch/x86/um/Kconfig                           |   1 +
>  fs/Kconfig.binfmt                             |   3 +
>  include/linux/elfcore.h                       |   4 +-
>  include/uapi/linux/elf.h                      |   3 +
>  12 files changed, 161 insertions(+), 5 deletions(-)
>  create mode 100644 arch/arm64/kernel/elfcore.c

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/5] arm64: mte: add core dump support

[Catalin Marinas]

On Wed, Dec 08, 2021 at 11:21:24AM -0600, Eric W. Biederman wrote:
> Catalin Marinas <catalin.marinas@arm.com> writes:
> > Add core dump support for MTE tags. When a core file is generated and
> > the user has mappings with PROT_MTE, segments with the PT_ARM_MEMTAG_MTE
> > type are dumped. These correspond to the PT_LOAD segments for the same
> > virtual addresses.
> 
> Why did you choose to encode this information as a program header
> instead of as a note?

That's how we started, even had binutils patches ready to merge until we
realised that elf64_note::n_descsz is 32-bit only.

For MTE, the tags need (vma_size / PAGE_SIZE * 128) bytes in the
coredump or 2^(vma_shift - 5). In theory a vma can be 52-bit, so we'd
need a theoretical 47-bit size for the content of a note.
elf64_phdr::p_filesz, OTOH, is a 64-bit value.

We could split this int multiple notes but, as I try to describe below,
I think its designation is closer to a PT_LOAD segment than a note
(well, without the load part).

> I also don't know what an MTE tag is.  A memory type extension?

Sorry, I should have described it in the cover letter: Memory Tagging
Extensions (pretty much like SPARC ADI). This hardware feature allows
every 16 bytes in memory to have an associated "tag". On access, the top
byte of the pointer (actually bits 59:56) are compared with the
in-memory tag. If they don't match, a fault is raised. Typical use-case:
heap allocators set a tag for a range of memory and return a pointer
with the corresponding top byte set. Out of bounds access or use after
free can be caught (with some probability since we only have 16 tags in
total).

Now, when we do a core dump, it would be useful to the debugger to know,
for a corresponding PT_LOAD segment, what the in-memory tags were, if
any.

> If this was something the loader would need when loading an application,
> and the loader could parse this program header as well that would
> definitely be justification for using a program header.

We don't currently have a use for the loader to parse this but it's
possible in theory to, say, tag some data or bss ranges with something
other than the default 0 (though most likely this would be the loader
picking a random tag rather than deciding its value at build-time).

Thanks.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel