From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101389 invoked by alias); 17 Jul 2019 15:18:09 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 101379 invoked by uid 89); 17 Jul 2019 15:18:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: mail-wr1-f65.google.com Received: from mail-wr1-f65.google.com (HELO mail-wr1-f65.google.com) (209.85.221.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Jul 2019 15:18:07 +0000 Received: by mail-wr1-f65.google.com with SMTP id r1so25251918wrl.7 for ; Wed, 17 Jul 2019 08:18:07 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id p12sm20359584wrt.13.2019.07.17.08.18.04 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 17 Jul 2019 08:18:05 -0700 (PDT) Subject: Re: [PATCH] AArch64 pauth: Indicate unmasked addresses in backtrace To: Simon Marchi , Alan Hayward References: <20190717081336.68835-1-alan.hayward@arm.com> <68E9D3EF-D6A5-44C9-A87C-916EC6970435@arm.com> Cc: gdb-patches@sourceware.org, nd From: Pedro Alves Message-ID: <9c474f28-30f3-2428-d147-4474471a61ba@redhat.com> Date: Wed, 17 Jul 2019 15:18:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2019-07/txt/msg00391.txt.bz2 On 7/17/19 4:01 PM, Simon Marchi wrote: > On 2019-07-17 09:35, Alan Hayward wrote: >>> On 17 Jul 2019, at 12:15, Pedro Alves wrote: >>> >>> On 7/17/19 9:14 AM, Alan Hayward wrote: >>>> Armv8.3-a Pointer Authentication causes the function return address to be >>>> obfuscated on entry to some functions. GDB must unmask the link register in >>>> order to produce a backtrace. >>>> >>>> The following patch adds markers of to the bracktrace, to indicate >>>> which addresses needed unmasking. >>>> >>>> For example, consider the following backtrace: >>>> >>>> (gdb) bt >>>> 0  0x0000000000400490 in puts@plt () >>>> 1  0x00000000004005dc in foo ("hello") at cbreak-lib.c:6 >>>> 2  0x0000000000400604 in bar () at cbreak-lib.c:12 >>>> 3  0x0000000000400620 in barbar () at cbreak.c:17 >>>> 4  0x00000000004005b4 in main () at cbreak-3.c:10 >>>> >>>> The functions in the cbreak-lib use pointer auth, obfuscating the return address >>>> to the previous function.  The caused the addresses of bar and barbar to require >>>> unmasking in order to unwind the backtrace. >>>> >>>> Alternatively, I considered replacing with a single chracter, such >>>> as * for brevity reasons, but felt this would be non obvious for the user. >>> >>> I don't have a particular suggestion, though my first reaction was that >>> it seemed a bit verbose. >>> >>> IMHO, the marker doesn't have to stand out and be expressive, since users can >>> always look at the manual. >> >> Reading the manual is an assumption I’m not sure is anywhere near the >> common case. >> Saying that, I agree we shouldn’t be designing the output for the non-readers. >> >> This comment has reminded me I need to add something to the manual as >> part of this >> patch. >> >> >>>  Once they learn something, often being concise >>> helps -- or in other words, once you learn what "" or "U" or whatever >>> is, and you're used to it, what would you rather see?  What's the main >>> information you're looking for when staring at the backtrace?  Thoughts >>> like that should guide the output too, IMO. >> >> PAC is the official abbreviation for the feature, so maybe :PAC works best. >> >> (gdb) bt >> 0  0x0000000000400490 in puts@plt () >> 1  0x00000000004005dc in foo ("hello") at cbreak-lib.c:6 >> 2  0x0000000000400604:PAC in bar () at cbreak-lib.c:12 >> 3  0x0000000000400620:PAC in barbar () at cbreak.c:17 >> 4  0x00000000004005b4 in main () at cbreak-3.c:10 >> >> >> Some of my attempts at different representations: >> 2  0x0000000000400604* in bar () at cbreak-lib.c:12 >> 2  0x0000000000400604! in bar () at cbreak-lib.c:12 >> 2  0x0000000000400604U in bar () at cbreak-lib.c:122 >> 2  0x0000000000400604:U in bar () at cbreak-lib.c:122 >> 2  0x0000000000400604 in bar () at cbreak-lib.c:12 >> 2  0x0000000000400604[U] in bar () at cbreak-lib.c:12 >> 2  0x0000000000400604 in bar () at cbreak-lib.c:12 >> 2  0x0000000000400604

in bar () at cbreak-lib.c:12 >> 2  0x0000000000400604 in bar () at cbreak-lib.c:12 >> 2  0x0000000000400604PAC in bar () at cbreak-lib.c:12 >> 2  0x0000000000400604:PAC in bar () at cbreak-lib.c:12 >> 2  0x0000000000400604,PAC in bar () at cbreak-lib.c:12 >> >> I found a single character was too hidden. A single character or symbol was also >> a little confusing - my brain read U as unsigned, * as pointer, [] as an array. >> >> I also like ,PAC as it might be easier to add future extensions. > > It might not be easily doable, but I think it would be nice if you could somehow make it so the function names stay aligned (regardless of which marker you end up choosing), like: > > 0  0x0000000000400490     in puts@plt () > 1  0x00000000004005dc     in foo ("hello") at cbreak-lib.c:6 > 2  0x0000000000400604 [U] in bar () at cbreak-lib.c:12 > 3  0x0000000000400620 [U] in barbar () at cbreak.c:17 > 4  0x00000000004005b4     in main () at cbreak-3.c:10 I almost suggested the same, but didn't when I realized that we don't always print the addresses: (top-gdb) bt #0 gdb_main (args=0x7fffffffd3a0) at src/gdb/main.c:1186 #1 0x0000000000469a7e in main (argc=1, argv=0x7fffffffd4a8) at src/gdb/gdb.c:32 But if you do want to align the addresses, you could do that by specifying a width for the "addr" column. If "[U]" is rare, given no column headers, the spaces may look a bit odd, though. Maybe you'd want to pre-compute the max column width by looking at the max number of frames that fit on a page, or something along those lines. Thanks, Pedro Alves