From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id FAVwHVUpk1+DagAAWB0awg (envelope-from ) for ; Fri, 23 Oct 2020 15:04:53 -0400 Received: by simark.ca (Postfix, from userid 112) id 6C00B1EE09; Fri, 23 Oct 2020 15:04:53 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 873C81E552 for ; Fri, 23 Oct 2020 15:04:52 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CA4FE385040B; Fri, 23 Oct 2020 19:04:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CA4FE385040B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1603479891; bh=6wl5expfJCeXUaOlgbW3Ne74eZXRZG9eoTneLt8fQ2I=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=Rh0HsnKK6fUeSsTPHV0IgqQJH7PZYjUSQm11REIro5UqADH9Slskwuss0UCMYkYgD hlmyqh6Gc3vVPlS0crZ9TbMcVS2Y2dwF/IPD09rmFrJOaV86KoDlGIXnD5GPwfAIap 3qSadOg6NKMaPODPoM6xb9I9pCJGcjVMSJJJDoyw= Received: from mail-qt1-x843.google.com (mail-qt1-x843.google.com [IPv6:2607:f8b0:4864:20::843]) by sourceware.org (Postfix) with ESMTPS id 672263858001 for ; Fri, 23 Oct 2020 19:04:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 672263858001 Received: by mail-qt1-x843.google.com with SMTP id e6so1772441qtw.10 for ; Fri, 23 Oct 2020 12:04:49 -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=6wl5expfJCeXUaOlgbW3Ne74eZXRZG9eoTneLt8fQ2I=; b=rojUI2ax8XanLMIqoTryznK9BEz9ndtfgrdthH50ZyFK3ljwc4EKkCVr9zA5flrBWd mgqcBL01ES1agkMXOWq3AR3HcYMFeKAIStYEC0vwmxQlx/iWlYxkkEBU0VMQtVv9nc4y cFTR8EatttfPxA8v+xzsvTsUcHfztYX61uLDLcZWWV6OGWIoyL573AVgs7usn9PMiLwW +aJVM2Qrk8rYeuMPcX1et2M7RMMrEANQuYGCr5GQh2Wcx/sEBcPXUL+X//YI9zAr3b64 pShBv4A9pE/LdZm4Gkpuxa26xUlldsRsrpWQZRgE01q6KpL1WxAeiHJVKyawWCLpmxwb vPXw== X-Gm-Message-State: AOAM531HsrDOWfDJwOh+smFydt+WMss+3dRIO1X1Q8L+VDiuiL8tyfes YRWXAYloELDERToEWkccOsPcuA== X-Google-Smtp-Source: ABdhPJz5zqXf+4+tTJs9pHS0QeaosXaezREvc3BXf8qOQOt2y6/I5cGE6ekbBsV5TJpPsDcmtZ9SEQ== X-Received: by 2002:ac8:8c7:: with SMTP id y7mr3668725qth.278.1603479888797; Fri, 23 Oct 2020 12:04:48 -0700 (PDT) Received: from ?IPv6:2804:7f0:8284:1487:4913:3c4b:c60f:1010? ([2804:7f0:8284:1487:4913:3c4b:c60f:1010]) by smtp.gmail.com with ESMTPSA id 9sm1392395qkv.110.2020.10.23.12.04.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Oct 2020 12:04:48 -0700 (PDT) Subject: Re: [PATCH v2 20/24] Documentation for the new mtag commands To: Eli Zaretskii References: <20201022200014.5189-1-luis.machado@linaro.org> <20201022200014.5189-21-luis.machado@linaro.org> <837drhla9o.fsf@gnu.org> <83y2jwj0dk.fsf@gnu.org> Message-ID: Date: Fri, 23 Oct 2020 16:04:45 -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: <83y2jwj0dk.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: , From: Luis Machado via Gdb-patches Reply-To: Luis Machado Cc: david.spickett@linaro.org, gdb-patches@sourceware.org Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" On 10/23/20 2:52 PM, Eli Zaretskii wrote: >> Cc: gdb-patches@sourceware.org, david.spickett@linaro.org >> From: Luis Machado >> Date: Fri, 23 Oct 2020 11:33:36 -0300 >> >> But, in general, there will always be a memory-side tag against which a >> logical tag (contained in a pointer, for example) will be matched against. > > This is the crucial aspect that should be stated, IMO. > I realized the order of the phrases was a bit off. I reordered it a bit and added to it. How does the following look? "Memory tagging is a memory protection technology that uses a pair of tags to validate memory accesses through pointers. The tags are integer values usually comprised of a few bits, depending on the architecture. There are two types of tags that are used in this setup: logical and allocation. A logical tag is stored in the pointers themselves, usually at the higher bits of the pointers. An allocation tag is the tag associated with particular ranges of memory in the physical address space, against which the logical tags from pointers are compared. The pointer tag (logical tag) must match the memory tag (allocation tag) for the memory access to be valid. If the logical tag does not match the allocation tag, that will raise a memory violation. Allocation tags cover multiple contiguous bytes of physical memory. This range of bytes is called a memory tag granule and is architecture-specific. For example, AArch64 has a tag granule of 16 bytes, meaning each allocation tag spans 16 bytes of memory. If the underlying architecture supports memory tagging, like AArch64 MTE or SPARC ADI do, @value{GDBN} can make use of it to validate addresses and pointers against memory allocation tags. A command prefix of @code{mtag} gives access to the various memory tagging commands." >>>> +@kindex mtag setltag >>>> +@item mtag setltag @var{address_expression} @var{tag_bytes} >>>> +Print the address given by @var{address_expression}, augmented with a logical >>> >>> It is strange for a command whose name is "set..." to print >>> something. I'd expect it to set something instead. is the above >>> description correct? >>> >> >> Yes. This is one area that I'd welcome some discussion/feedback. >> >> We don't always have a modifiable value as an argument to the "mtag >> setltag" command. We could have a constant value, a read-only value, >> some reference or some expression containing multiple pointers. >> >> Plus, the most natural way to modify a value in GDB is through the >> existing "set variable" command. >> >> The main goal is to be able to augment a particular address with a given >> logical tag. That augmented value can then be used to set a particular >> pointer or value. It will be stored in the history anyway, so that's >> already a value that you can use. >> >> There won't be much reason to set logical tags other than if you're >> chasing bugs and trying to cause one. It is one additional knob so that >> you won't need to craft the tagged pointer by hand. > > Maybe the command should be called something other than "set...", > then? > Maybe. Though honestly I'm not really sure what to call it. Even if we call it "set" and make it really set some variable's value, it won't be able to set the value of an expression with multiple variables, for example. I'll have to think about it. >>>> +@kindex mtag check >>>> +@item mtag check @var{address_expression} >>>> +Check that the logical tag stored at the address given by >>>> +@var{address_expression} matches the allocation tag for the same address. >>> >>> This test should say that this check performs the same validation as >>> is done in hardware when memory is accessed through a pointer. Saying >>> that (assuming I understood correctly) will go a long way towards >>> causing this facility to make much more sense to the reader. >> >> Does it make it more clear if I add the following: >> >> "This essentially emulates the hardware validation that is done when >> tagged memory is accessed through a pointer, but does not cause a memory >> fault as it would during hardware validation. >> >> It can be used to inspect potential memory tagging violations in the >> running process, before any faults get triggered." > > Yes, this is a good addition, thanks. > Thanks. Fixed now.