From patchwork Mon Jan 31 16:54:51 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Catalin Marinas X-Patchwork-Id: 12730900 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 BD53CC433FE for ; Mon, 31 Jan 2022 17:03:18 +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:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=gdTusQza0J1OaBLmlauchA88+apXUm3GGVg7gPPimqg=; b=qth2Njs7YcAh2f rquRXFzx1MCa6aR9tc+E9pS3ssRMyZqUmnRTvALvWIYWIKO3EBotieUdM3mhYkukq4PXE/sBqlEdS jOP6y3t59TyiLnuAudolzapLrnyun5gB6ZqOB8E0Ov/4c/T40rgcZt71CCugIah2GZaH9gIcQNmlP WLlVI7VHZhS+rBGtM2hAUI+tWdWtYyVeXmSp4uwcMevVLdtA6pJ1MLWhTgmDv0YG70yGOdafrtS99 BD8VEXLb9W+RWaI80dvMT1T6y+T65AKXIpVFNx+704CcSOUaM1tbS2lGb40Q8rpNj/4SyBi/wnl50 cgsbPWopY8FkWjAJQVDw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nEa3I-009yUi-GG; Mon, 31 Jan 2022 17:01:16 +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 1nEZxK-009wsO-Ed for linux-arm-kernel@lists.infradead.org; Mon, 31 Jan 2022 16:55:08 +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 67F5AB82BB0; Mon, 31 Jan 2022 16:55:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5D492C340E8; Mon, 31 Jan 2022 16:55:00 +0000 (UTC) From: Catalin Marinas To: linux-arm-kernel@lists.infradead.org Cc: Will Deacon , Luis Machado , John Baldwin , Arnd Bergmann , "Eric W. Biederman" , Szabolcs Nagy , Andrew Morton Subject: [PATCH v2 0/5] arm64: mte: add core dump support Date: Mon, 31 Jan 2022 16:54:51 +0000 Message-Id: <20220131165456.2160675-1-catalin.marinas@arm.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220131_085506_863369_6A392F2D X-CRM114-Status: GOOD ( 18.05 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, This is the second version of the core dump support for MTE tags. Changes since v1 (https://lore.kernel.org/r/20211208121941.494956-1-catalin.marinas@arm.com): - Made the documentation slightly clearer on what the size of a segment. - Added Luis' acks. - Rebased to 5.17-rc2. The arm64 Memory Tagging Extensions allow assigning a 4-bit (allocation) tag to a 16-byte memory range. Bits 56..59 of a pointer are checked against the allocation tag on access and a fault may be raised if there's a mismatch. The additional 4-bit metadata is useful for debugging hence this series to dump it to the core file. 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 choice of an ELF segment rather than a note was made due to the 32-bit size limitation of a note which would only cover vmas up to 37-bit. The last patch documents the core file format. The tags are dumped packed, two 4-bit 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+0x1 0x05b000 0x0000ffff80034000 0x0000000000000000 0x000100 0x002000 0 LOPROC+0x1 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 | 23 ++++ 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, 162 insertions(+), 5 deletions(-) create mode 100644 arch/arm64/kernel/elfcore.c