From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id sO4uD2XLEWA2TwAAWB0awg (envelope-from ) for ; Wed, 27 Jan 2021 15:21:57 -0500 Received: by simark.ca (Postfix, from userid 112) id 3819D1EF8A; Wed, 27 Jan 2021 15:21:57 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_NONE,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (unknown [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 AAC5C1E590 for ; Wed, 27 Jan 2021 15:21:55 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 55070398B871; Wed, 27 Jan 2021 20:21:54 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 55070398B871 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1611778914; bh=8nqNDjG/44MwPZd2wDzAKmyiTeJkLuwhMxdK2oLDtDw=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=YdPicIMgZCuKGUb/ZU1ry1cxBTkeGL8nBFJeu0xpIQCANKic10tL/gODQg0MjnWDu xWTmZLUH6iTd+lfPXmWU/KGUqFBuxT1y1fIXdRxO2s1IZ36GhVFrabVhhWEKzlyKX8 ia3GXw+chHgH+a0CNVo9lJ9pNB+aUDUR6CF4ZzDA= Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) by sourceware.org (Postfix) with ESMTPS id 02977398B871 for ; Wed, 27 Jan 2021 20:21:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 02977398B871 Received: by mail-qv1-xf2d.google.com with SMTP id es14so1733663qvb.3 for ; Wed, 27 Jan 2021 12:21:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=8nqNDjG/44MwPZd2wDzAKmyiTeJkLuwhMxdK2oLDtDw=; b=f1NnYm2JeyBGaMq1o8Kr7CGQiPERuyUHWgHZVjK3/ucnd1WzmA8CdXf76TRrcnh7pg GqXIYjijZ30wyIbN6ZEadjQSi3UNINVek3Hg/4XRH80W2m/yjFAOrny4Ddlokw09lxXl fiK18FVWCz3Lxw9ezwRgQlq3q3mb9rYqxORIMe7ol88WI+k3EOLAPhyrPI8IXzoyb966 Bye7ExtyAatUwE77+F2OuQzf8VW7L8FIfYf927fMmBWkZlxhExmKt2tUEwrweaRsG1o7 ZdTYaJVngSDf5MZOxuVzNyjXVpC6yPYbNxWIF8qJlKnE7ZI7kKq0Yqca+ham2AXEhDQa qWlw== X-Gm-Message-State: AOAM531K+fOAhpLzVATurRWQuA3K6H/jS8bMsQIjjpzhwdKRiDXBWmhj pioQtW0YAALs3k5VWqr37Km3DjS/MgAvWQ== X-Google-Smtp-Source: ABdhPJzv86aocxZnr737xZ1COilhDz70N5Bvx3ndVkPgSzQgzo+suqxdPyWnt4INDF9B8RSaROoc6g== X-Received: by 2002:ad4:53ab:: with SMTP id j11mr5427090qvv.1.1611778911518; Wed, 27 Jan 2021 12:21:51 -0800 (PST) Received: from localhost.localdomain ([2804:7f0:8284:874d:b82c:87fc:4324:adab]) by smtp.gmail.com with ESMTPSA id b194sm1854531qkc.102.2021.01.27.12.21.50 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Jan 2021 12:21:51 -0800 (PST) To: gdb-patches@sourceware.org Subject: [PATCH v5 21/25] Documentation for the new mtag commands Date: Wed, 27 Jan 2021 17:21:08 -0300 Message-Id: <20210127202112.2485702-22-luis.machado@linaro.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20210127202112.2485702-1-luis.machado@linaro.org> References: <20210127202112.2485702-1-luis.machado@linaro.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" Updates on v4: - Update the command names. -- Document the new "memory-tag" command prefix and all of its subcommands. gdb/doc/ChangeLog: YYYY-MM-DD Luis Machado * gdb.texinfo (Memory Tagging): New subsection and node. (AArch64 Memory Tagging Extension): New subsection. --- gdb/doc/gdb.texinfo | 97 ++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 96 insertions(+), 1 deletion(-) diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index a10a74d0c3..f751bdf4d3 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -10848,6 +10848,66 @@ target supports computing the CRC checksum of a block of memory (@pxref{qCRC packet}). @end table +@node Memory Tagging +@subsection Memory Tagging + +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{memory-tag} gives access to the various memory tagging +commands. + +The @code{memory-tag} commands are the following: + +@table @code +@kindex memory-tag print-logical-tag +@item memory-tag print-logical-tag @var{address_expression} +Print the logical tag stored at the address given by @var{address_expression}. +@kindex memory-tag with-logical-tag +@item memory-tag with-logical-tag @var{address_expression} @var{tag_bytes} +Print the address given by @var{address_expression}, augmented with a logical +tag of @var{tag_bytes}. +@kindex memory-tag print-allocation-tag +@item memory-tag print-allocation-tag @var{address_expression} +Print the allocation tag associated with the memory address given by +@var{address_expression}. +@kindex memory-tag setatag +@item memory-tag 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}. +@kindex memory-tag check +@item memory-tag 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 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. +@end table + @node Auto Display @section Automatic Display @cindex automatic display @@ -24966,6 +25026,41 @@ When GDB prints a backtrace, any addresses that required unmasking will be postfixed with the marker [PAC]. When using the MI, this is printed as part of the @code{addr_flags} field. +@subsubsection AArch64 Memory Tagging Extension. +@cindex AArch64 Memory Tagging Extension. + +When @value{GDBN} is debugging the AArch64 architecture, the program is +using the v8.5-A feature Memory Tagging Extension (MTE) and there is support +in the kernel for MTE, @value{GDBN} will make memory tagging functionality +available for inspection and editing of logical and allocation tags. +@xref{Memory Tagging}. + +To aid debugging, @value{GDBN} will output additional information when SIGSEGV +signals are generated as a result of memory tag failures. + +If the tag violation is synchronous, the following will be shown: + +@smallexample +Program received signal SIGSEGV, Segmentation fault +Memory tag violation while accessing address 0x0000fffff7ff8000 +Allocation tag 0x0000000000000001. +@end smallexample + +If the tag violation is asynchronous, the fault address is not available. +In this case @value{GDBN} will show the following: + +@smallexample +Program received signal SIGSEGV, Segmentation fault +Memory tag violation +Fault address unavailable. +@end smallexample + +A special register, @code{tag_ctl}, is made available through the +@code{org.gnu.gdb.aarch64.mte} feature. This register exposes some +options that can be controlled at runtime and emulates the @code{prctl} +option @code{PR_SET_TAGGED_ADDR_CTRL}. For further information, see the +documentation in the Linux kernel. + @node i386 @subsection x86 Architecture-specific Issues @@ -41023,7 +41118,7 @@ does not have any restriction on alignment or size. @var{length} is the length, in bytes, of the memory range. -@var{type} is the type of tag the request wants to fetch. The typeis a signed +@var{type} is the type of tag the request wants to fetch. The type is a signed integer. @var{tag bytes} is a sequence of hex encoded uninterpreted bytes which will be -- 2.25.1