From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) by sourceware.org (Postfix) with ESMTPS id A7CE5386F457 for ; Thu, 23 Jul 2020 13:59:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A7CE5386F457 Received: by mail-qk1-x744.google.com with SMTP id d14so5338009qke.13 for ; Thu, 23 Jul 2020 06:59:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mzY9MZqkv/PNzfOLw7FGWKeTnO3VYceqGy7/0rYlcSs=; b=ubFZxDu0VIAwry7TcnEYNVMYmuSMTMlFtlQP8UHL6lwow2MtZdT0Pz4TaV15ZVzhPx FY/7lnCBPffQlz2mQxKfVuJA/o+DNdmpa8bYiIkRujHDxoHXGYkeF7KEP7C0E/etDPhm VRN5q6bj1SBpyk/5HP1GgO/my+wu2W722sRpXkaXB1Aseg5WghldhLbWGT73mj0ND2XP KVLDXmQZbPNM6x22WLRsU5+YKQwX0ajiwmsy+L2HkQi/ejN0CeRGlv7ys4ae7j6JDOLE 6dUFSZK9bJsTrVb3FqmFySjF43d81gNDphyVBBzpyVkOC6GH0liSMJuYME47VdHzW4pj B0Sw== X-Gm-Message-State: AOAM532TLHTUhqT/6GP+AVlJN07owLvFVpeZkcVo7TFSLzrMJ25lbzTh RXVGZvjW8XhUCfQo3usQ36MZBQ== X-Google-Smtp-Source: ABdhPJw5KoEz8OOJ0WjPUH99TUvPdR8m83jpn5m0i1es+eEfQ1YONiSoKD0QiwJy2fHP6hNZZ8ESJw== X-Received: by 2002:a37:e86:: with SMTP id 128mr5079952qko.314.1595512773143; Thu, 23 Jul 2020 06:59:33 -0700 (PDT) Received: from ?IPv6:2804:7f0:8283:4d57:c15e:e2c3:f855:dba0? ([2804:7f0:8283:4d57:c15e:e2c3:f855:dba0]) by smtp.gmail.com with ESMTPSA id s127sm2652479qka.85.2020.07.23.06.59.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Jul 2020 06:59:32 -0700 (PDT) Subject: Re: [PATCH 00/23] Memory Tagging Support + AArch64 Linux implementation To: John Baldwin , gdb-patches@sourceware.org, Alan.Hayward@arm.com Cc: david.spickett@linaro.org, Omair Javaid References: <20200715194513.16641-1-luis.machado@linaro.org> From: Luis Machado Message-ID: <80627efe-3aa2-fe0d-98e3-b7e7640d3904@linaro.org> Date: Thu, 23 Jul 2020 10:59:29 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, 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: Thu, 23 Jul 2020 13:59:35 -0000 Hi, On 7/17/20 7:02 PM, John Baldwin wrote: > 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. The use of a value instead of a CORE_ADDR means we can pass in data without having to worry about limits of the underlying data type. If we have a data type of more than 16 bytes, we wouldn't have to worry about conversions, truncation etc. For example, we may need to bump the data type to int128 to store addresses larger than 64-bit, but that data type may not be available everywhere. LLDB has APInt's that can deal with integers of arbitrary size, but in GDB we don't have such a type. The closest is struct value. > > - 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. That sounds reasonable, but I'd still like to leave the interpretation of the type field to the target-specific code. Remote stubs would just parse the field and pass it on to the target-specific layers. Out of curiosity, what other types of tags do you think could be used in the future? > > - 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. I'm open to suggestions, but right now the two candidates we have are ADI "versions" and MTE "tags". We need a way to distinguish between the memory tags and the pointer tags. "mtag", "atag" and "ltag" are documented in the manual so developers can understand what their purpose is, even though those may not match their particular architecture naming scheme. GDB can also put together aliases for the commands, so targets can define their own naming scheme for memory tagging commands. > > - 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 Sounds good. I'll rebase on top of that when it gets pushed.