From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 306E1C433EF for ; Wed, 8 Dec 2021 17:59:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=d0vqi7RgKSJXEO6mnzUu2ISA4XsYt8nrQSzwXgyR02Y=; b=btQny75ITp+714 jsHG3F0gsLOxavjpJmqDSr2Fh+rJsoIxrGhZdV2al/adt7O2/AulFsveFNnk8xEeCqfqiDAyePApt Tnu9iGIqkyP52aGEp21HV3WsHZkYA7dumdO2GyXZVJW3btmz8PSAVszku9MOxoPVLYN/WmSOiLPcN 8U8HNr/HEZsP/CyhO62qQpSbtQMHTIfHuIqym22rtwyibeB/KrAzv1kyJdjxk1tXO/9G7OJpGf0Kq QQlsM4Ieo6Bk4VzGjK4uVxn3ZQ8pooMPEyG3dxOERH4t2GTOGAEisBkkeTlaETksgr6Z+jyehy4aS x+/opkh1Gkrg7JGmJ+bg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mv1CY-00DoZ1-VZ; Wed, 08 Dec 2021 17:57:59 +0000 Received: from ams.source.kernel.org ([2604:1380:4601:e00::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mv1CU-00DoXj-QZ for linux-arm-kernel@lists.infradead.org; Wed, 08 Dec 2021 17:57:56 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 5DE02B821F3; Wed, 8 Dec 2021 17:57:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 65F4EC00446; Wed, 8 Dec 2021 17:57:50 +0000 (UTC) Date: Wed, 8 Dec 2021 17:57:47 +0000 From: Catalin Marinas To: "Eric W. Biederman" Cc: linux-arm-kernel@lists.infradead.org, Will Deacon , Luis Machado , John Baldwin , Arnd Bergmann , Kees Cook , Szabolcs Nagy , Andrew Morton Subject: Re: [PATCH 0/5] arm64: mte: add core dump support Message-ID: References: <20211208121941.494956-1-catalin.marinas@arm.com> <8735n3812j.fsf@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <8735n3812j.fsf@email.froward.int.ebiederm.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211208_095755_029494_39E44C87 X-CRM114-Status: GOOD ( 23.51 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Dec 08, 2021 at 11:21:24AM -0600, Eric W. Biederman wrote: > Catalin Marinas 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