From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id xCd2AMrpkl8NYwAAWB0awg (envelope-from ) for ; Fri, 23 Oct 2020 10:33:46 -0400 Received: by simark.ca (Postfix, from userid 112) id E8DF31EE09; Fri, 23 Oct 2020 10:33:45 -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 0E9DC1E58D for ; Fri, 23 Oct 2020 10:33:45 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 514393858036; Fri, 23 Oct 2020 14:33:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 514393858036 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1603463624; bh=DwWfeHoTW0fx130T1cWF4R6XxPxtf9ax7ExOlCitDq8=; 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=pccQMTd5zXrF2/99DkkRk9fvM18eoVd0cVJWyrpDcHziubdC2KvAt0xGGruB4zECt F+xRpIWAmQGQbRutgFJhNPXkU83nSUIbzd5Gd1DuRyWEJyAdnAWuDOoLksj6TpnqoN hflbqjJR3D7Sd/mbfnXbIyOy3SRccVr7zLBvVE44= Received: from mail-qv1-xf43.google.com (mail-qv1-xf43.google.com [IPv6:2607:f8b0:4864:20::f43]) by sourceware.org (Postfix) with ESMTPS id B63253858036 for ; Fri, 23 Oct 2020 14:33:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B63253858036 Received: by mail-qv1-xf43.google.com with SMTP id g13so777034qvu.1 for ; Fri, 23 Oct 2020 07:33:41 -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=DwWfeHoTW0fx130T1cWF4R6XxPxtf9ax7ExOlCitDq8=; b=VdcneJ2XNo9QzkQM89fcPW+CqhRdE7FrnPMqP1rNi0detOHmGufCLlRZja0gjHkr5h PXMZYHpmcR2Tkag8wevliJrHytvANw3EThRkzs/UByhHiNEqpvA5MGAaZaEAxengSix+ rgm0fX0dVNhmwZEWXUxeUO8dhpAIbR5dT34NdRQ53w7oshiF9vjX8cFQWzJeRQepGNGS qpFbEFp1XIg3jjpNrReC2LYUFw0xnrJXepqvB6xLoIjGPwZ+UO1XLyk9KcNEPwwnGeEB mTaStzlwwgKu4A5Px/pZK+1AXcHPbTdU/0W8Lcd/dQBkb+HeNXC4dr6XDarSRuG9eZsC a8HA== X-Gm-Message-State: AOAM530Dk9GpyxDhZfkeDUPZyDCULD+z7Z8y5hPFrGC+TwozGzd3D5xP 2/LqEWcQYCz9okcsrTP8i5+GJS3C5XX1Tw== X-Google-Smtp-Source: ABdhPJyDoo2UHGpd6iQ3ULX5rrIJY3qz3pb8dcdWT0zgiOAPuDrOgA9BxXEHsdPXlkjP/XcM4AcURA== X-Received: by 2002:ad4:5547:: with SMTP id v7mr2504808qvy.9.1603463619937; Fri, 23 Oct 2020 07:33:39 -0700 (PDT) Received: from [192.168.15.3] ([191.249.230.151]) by smtp.gmail.com with ESMTPSA id p127sm855560qkc.37.2020.10.23.07.33.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Oct 2020 07:33:39 -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> Message-ID: Date: Fri, 23 Oct 2020 11:33:36 -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: <837drhla9o.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 3:35 AM, Eli Zaretskii wrote: >> Date: Thu, 22 Oct 2020 17:00:10 -0300 >> From: Luis Machado via Gdb-patches >> Cc: david.spickett@linaro.org >> >> +Memory tagging is a memory protection technology that uses tags to validate >> +memory accesses through pointers. The pointer tag must match the memory tag >> +for the memory access to be validated. > ^^^^^^^^^^^^^^^ > I guess "to be valid" is more clear, as "validated" can be interpreted > as the process of validation, not its result. > That makes sense. I've updated the text to say "valid". >> +There are two types of tags: logical and allocation. A logical tag is >> +stored in the pointers themselves. A allocation tag is the tag associated > ^ ^^^ > "An" and "a" > Fixed. > Also, this text fails to explain that (AFAIU) these 2 types of tags > work together to allow the access validation. IOW, both types need to > be present for the mechanism to work. I originally interpreted the > text as meaning that tags come in 2 flavors, depending on how the > hardware implemented the facility. > I can add a bit more text describing that. But things can get a bit confusing in the future as we support more tags of different types. For example, CHERI capability tags are similar to logical tags, but you can't set those. 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. >> +@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. >> +@item mtag setatag @var{starting_address} @var{length} @var{tag_bytes} >> +Set the allocation tag(s) for memory range @r{[}@var{starting_address}, >> +@var{starting_address} + @var{length}@r{)} to @var{tag_bytes}. > > This is what I'd expect from setltag to do. > Yeah. But contrary to the logical tag, we can always set the allocation tag in memory. Given a particular expression that gets evaluated to an address, we can always set a tag at that address. There's no lval/non-lval issues here. With logical tags this is only possible if you evaluate the expression to an address and then tweak the resulting address to contain a particular logical tag. That's why we print the resulting adjusted address as opposed to modifying some pointer/variable. >> +@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."