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

From: Catalin Marinas <catalin.marinas@arm.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-arm-kernel@lists.infradead.org,
	Will Deacon <will@kernel.org>,
	Luis Machado <luis.machado@linaro.org>,
	John Baldwin <jhb@freebsd.org>, Arnd Bergmann <arnd@arndb.de>,
	Kees Cook <keescook@chromium.org>,
	Szabolcs Nagy <szabolcs.nagy@arm.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 0/5] arm64: mte: add core dump support
Date: Wed, 8 Dec 2021 17:57:47 +0000	[thread overview]
Message-ID: <YbDyG5f5r+lfeudu@arm.com> (raw)
In-Reply-To: <8735n3812j.fsf@email.froward.int.ebiederm.org>

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