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 29DDEC433F5 for ; Wed, 8 Dec 2021 17:23:19 +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:Subject:MIME-Version:Message-ID: In-Reply-To:Date:References:Cc:To:From:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=jvGSAIQ6e49vCKqYUzU450ZYvuHjPxuEqnIzREYx7/U=; b=0Fgmohzn0+ijqGrZH09anXNTxk cOMLjL54pt2A5FWbiZoR+q3myuGMSHpVNiKg2LT6VZ6s3YAb7zaETcgYkPUjQwIj9IyDEHSxSmdNl 1/fIvryXT6EhxV8jRPXvja8km2ft+ihRpRLu/zbyuQKVCM/TFi9R4cyTnBTz23AP4b1n0pNnehRKX De10S/lgxbBHmla4Irl5PMVFKmnwvfKtLIu1P7NyVRNyvGutc3+95yc/ZOmam/zN93iAVkRLvVgbM f4ZwzUoCO0zyBRIww/4v12AJQAieG+91gFSckiCDdJ31Zq8JeyBnOTB6mF0KPxYYONLPwHz2w8VzR LH+3HnZA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mv0de-00Di1q-Sy; Wed, 08 Dec 2021 17:21:55 +0000 Received: from out01.mta.xmission.com ([166.70.13.231]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mv0db-00DhxJ-Dq for linux-arm-kernel@lists.infradead.org; Wed, 08 Dec 2021 17:21:52 +0000 Received: from in02.mta.xmission.com ([166.70.13.52]:36028) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mv0dJ-00GdYK-VH; Wed, 08 Dec 2021 10:21:34 -0700 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95]:58292 helo=email.froward.int.ebiederm.org.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1mv0dH-00C540-Vy; Wed, 08 Dec 2021 10:21:33 -0700 From: ebiederm@xmission.com (Eric W. Biederman) To: Catalin Marinas Cc: linux-arm-kernel@lists.infradead.org, Will Deacon , Luis Machado , John Baldwin , Arnd Bergmann , Kees Cook , Szabolcs Nagy , Andrew Morton References: <20211208121941.494956-1-catalin.marinas@arm.com> Date: Wed, 08 Dec 2021 11:21:24 -0600 In-Reply-To: <20211208121941.494956-1-catalin.marinas@arm.com> (Catalin Marinas's message of "Wed, 8 Dec 2021 12:19:36 +0000") Message-ID: <8735n3812j.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-XM-SPF: eid=1mv0dH-00C540-Vy; ; ; mid=<8735n3812j.fsf@email.froward.int.ebiederm.org>; ; ; hst=in02.mta.xmission.com; ; ; ip=68.227.160.95; ; ; frm=ebiederm@xmission.com; ; ; spf=neutral X-XM-AID: U2FsdGVkX19tpO2hyOJErMj8ImSxYpqEh1enqC0Vrm0= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH 0/5] arm64: mte: add core dump support X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211208_092151_499134_34C4A019 X-CRM114-Status: GOOD ( 22.42 ) 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 Catalin Marinas 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