From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.freebsd.org (mx2.freebsd.org [96.47.72.81]) by sourceware.org (Postfix) with ESMTPS id 0FAB63857004 for ; Fri, 17 Jul 2020 22:02:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0FAB63857004 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=FreeBSD.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jhb@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id A2F32749B9; Fri, 17 Jul 2020 22:02:52 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B7lVN2lt2z4bJh; Fri, 17 Jul 2020 22:02:52 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-274.local (unknown [IPv6:2601:648:8203:2990:a49c:d31e:c824:33c0]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id B32311CEE7; Fri, 17 Jul 2020 22:02:51 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: [PATCH 00/23] Memory Tagging Support + AArch64 Linux implementation To: Luis Machado , gdb-patches@sourceware.org, Alan.Hayward@arm.com Cc: catalin.marinas@arm.com, david.spickett@linaro.org References: <20200715194513.16641-1-luis.machado@linaro.org> From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Fri, 17 Jul 2020 15:02:49 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200715194513.16641-1-luis.machado@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 22:02:54 -0000 On 7/15/20 12:44 PM, Luis Machado via Gdb-patches wrote: > This patch series implements general memory tagging support for GDB, as well > as an implementation for AArch64 Linux. > > Memory tagging improves memory safety by tagging various parts of memory and > raising exceptions when the allocation tag (the one associated with a range of > memory addresses) does not match the logical tag contained in a pointer that is > used to access the memory area. > > We already have an implementation of such a mechanism for sparc64 (ADI), but > it is target-specific and not exposed to the rest of GDB. This series aims to > make the infrastructure available to other targets that may wish to support > their specific memory tagging approaches. For AArch64 Linux this is called > MTE (Memory Tagging Extensions). > > The series is split into a set that deals with generic changes to GDB's > infrastructure (target methods, gdbarch hooks and remote packets), a set that > implements support for AArch64 Linux and one last set that implements new > commands, updates the documentation and adds tests. > > The goal is to make it so the architecture independent parts of GDB don't > need to interpret tag formats, given the formats are likely different > for each architecture. For this reason, GDB will handle tags as a sequence of > bytes and will not assume a particular format. > > The architecture-specific code can handle the sequence of bytes appropriately. I only have a couple of thoughts but think this is fine overall. - For patch 2, I'm not sure the address needs to be a 'struct value' as opposed to just being a CORE_ADDR? The earlier reference I had made to storing tags with a value was more about having a way to bundle a tag together with the "normal" value at a given memory location, but not using a value to describe the address of a tag. - One thing I do see is that this currently assumes only a single memory tag type for a given architecture, but there may be architectures in the future which have multiple types of tags. For APIs we can always add that later if needed, but retroactively adding it to the remote protocol might prove more sticky. One alternative might be to do something like qMemTags::
: and similarly for QMemTags. For MTE could be "MTE" or "mte". In the case that an architecture provides multiple tag types, then could be used to disambiguate. - It might be better to not refer to tags specifically as "allocation tags" in the generic code like gdbarch.*. I do think the 'mtag' commands are also still a bit MTE-specific, but that is probably fine for now. - p/x is very nice - Very orthogonal: in a branch I have a change to make gdbarch_handle_segmentation_fault more generic so it is not specific to SIGSEGV but is instead able to report information for any signal. I will try to extract that as a separate RFC. -- John Baldwin