From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id aXPONybzd2H/YQAAWB0awg (envelope-from ) for ; Tue, 26 Oct 2021 08:23:02 -0400 Received: by simark.ca (Postfix, from userid 112) id CC7ED1F0BF; Tue, 26 Oct 2021 08:23:02 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,UNPARSEABLE_RELAY, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.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 3425F1EDDB for ; Tue, 26 Oct 2021 08:23:00 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id ECBD53858015 for ; Tue, 26 Oct 2021 12:22:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org ECBD53858015 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1635250980; bh=i/0NYqPba6AMz95RCOd4bSJbtEUh/zUw5yju9Ku1ikk=; h=Subject:To:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=ExusBiFK3BlDmCAB3lT8hIIqVzm4xnVkmtNjev9zLAj00H8qtUM2aLL4GgHCziQz4 /rwTNbCWD0XtD24nNmViy+Yty1C33lYvSTFmExGvXfOl2FKVfBb8MJtqVq4pA2Mr3F C/onfS7XCQjzoABrbyFBAcNftllBYMs+UD1o3eqA= Received: from mailgw02.mediatek.com (unknown [210.61.82.184]) by sourceware.org (Postfix) with ESMTPS id 74C5A3858C27 for ; Tue, 26 Oct 2021 12:22:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 74C5A3858C27 X-UUID: 58d52c4335604dfc86ee749f1c45ca66-20211026 X-UUID: 58d52c4335604dfc86ee749f1c45ca66-20211026 Received: from mtkexhb02.mediatek.inc [(172.21.101.103)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-SHA384 256/256) with ESMTP id 2014796427; Tue, 26 Oct 2021 20:22:28 +0800 Received: from mtkcas11.mediatek.inc (172.21.101.40) by mtkmbs10n2.mediatek.inc (172.21.101.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.2.792.3; Tue, 26 Oct 2021 20:22:26 +0800 Received: from mtksdccf07 (172.21.84.99) by mtkcas11.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 26 Oct 2021 20:22:26 +0800 Message-ID: <17ca411d3caeb54bbe6535676c12e8dc61a0f2d2.camel@mediatek.com> Subject: Re: [PATCH] AArch64 pauth: Indicate addresses in backtrace for kernel To: Luis Machado , "gdb-patches@sourceware.org" Date: Tue, 26 Oct 2021 20:22:26 +0800 In-Reply-To: References: <20211025114705.32548-1-Kuan-Ying.Lee@mediatek.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-MTK: N 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: Kuan-Ying Lee via Gdb-patches Reply-To: Kuan-Ying Lee Cc: James Hsu =?UTF-8?Q?=28=E5=BE=90=E6=85=B6=E8=96=B0=29?= , Nicholas Tang =?UTF-8?Q?=28=E9=84=AD=E7=A7=A6=E8=BC=9D=29?= , Zhiyong Wang =?UTF-8?Q?=28=E7=8E=8B=E5=BF=97=E5=8B=87=29?= , Chinwen Chang =?UTF-8?Q?=28=E5=BC=B5=E9=8C=A6=E6=96=87=29?= Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On Mon, 2021-10-25 at 20:07 +0800, Luis Machado wrote: > On 10/25/21 8:47 AM, Kuan-Ying Lee via Gdb-patches wrote: > > Armv8.3-a Pointer Authentication cause the function return address > > to > > be changed. GDB need to use address bit[55] to know which mode is > > active > > and mask/unmask the link register in order to get backtrace. > > > > If address is in kernel mode, we mask the address. If address is in > > user mode, > > we need to unmask the address. > > --- > > gdb/aarch64-tdep.c | 5 ++++- > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > diff --git a/gdb/aarch64-tdep.c b/gdb/aarch64-tdep.c > > index 4b5af4616af..d4bb4305cea 100644 > > --- a/gdb/aarch64-tdep.c > > +++ b/gdb/aarch64-tdep.c > > @@ -257,7 +257,10 @@ aarch64_frame_unmask_lr (struct gdbarch_tdep > > *tdep, > > { > > int cmask_num = AARCH64_PAUTH_CMASK_REGNUM (tdep- > > >pauth_reg_base); > > CORE_ADDR cmask = frame_unwind_register_unsigned > > (this_frame, cmask_num); > > - addr = addr & ~cmask; > > + if (addr & 0x0080000000000000ULL) > > + addr = addr | cmask; > > + else > > + addr = addr & ~cmask; > > > > /* Record in the frame that the link register required > > unmasking. */ > > set_frame_previous_pc_masked (this_frame); > > > Hi Luis, Thanks for your reply. I think I use the misunderstanding words 'mask' and 'unmask'. I will use 'unmangle' in the v2 commit message instead. Backtrace needs to be printed as unmangle address not only in kernel mode but also user mode. However, when we use arm64, kernel address will start with 0xffff.... and user mode address will start with 0x0000.... High bits in kernel address and user mode address are different. Thus, I think we should do the following two things. 1. If address is in kernel mode. Unmangle the kernel address by 'addr | cmask'. 2. If address is in user mode. Unmangle the user mode address by 'addr & ~cmask' We can see this kernel patch [1] use different unmangle method for user mode and kernel mode. After my patch, we can parse kernel backtrace as below. (address starts with 0xffff...) (gdb)bt #0 0xffffffdc252a5c44 in crash_setup_regs (newregs=0xffffffdc252b54a8, oldregs=0x0) at /mfs/mtkslt1092/mtk21026/CAS_REAL/alps-mp-s0_mp1 --2021_09_28_11_00/merged/kernel-5.10/arch/arm64/include/asm/kexec.h:45 #1 ipanic (this=, event=, ptr=) at /mfs/mtkslt1092/mtk21026/CAS_REAL/alps-mp-s0_mp1 --2021_09_28_11_00/merged/kernel- 5.10/drivers/misc/mediatek/aee/mrdump/mrdump_panic.c:259 #2 0xffffffdc291acbe8 [PAC] in notifier_call_chain (nl=, val=, v=, nr_to_call=, nr_calls=0x0) at /mfs/mtkslt1092/mtk21026/CAS_REAL/alps-mp-s0_mp1 --2021_09_28_11_00/merged/kernel-5.10/kernel/notifier.c:83 #3 atomic_notifier_call_chain (nh=, val=0, v=0xffffffdc2c3aa1c8 ) at /mfs/mtkslt1092/mtk21026/CAS_REAL/alps-mp-s0_mp1 --2021_09_28_11_00/merged/kernel-5.10/kernel/notifier.c:217 #4 0xffffffdc291acbe8 [PAC] in notifier_call_chain (nl=, val=, v=, nr_to_call=, nr_calls=0x0) at /mfs/mtkslt1092/mtk21026/CAS_REAL/alps-mp-s0_mp1 --2021_09_28_11_00/merged/kernel-5.10/kernel/notifier.c:83 #5 atomic_notifier_call_chain (nh=, val=18446743919823523840, v=0x0) at /mfs/mtkslt1092/mtk21026/CAS_REAL/alps-mp-s0_mp1 --2021_09_28_11_00/merged/kernel-5.10/kernel/notifier.c:217 #6 0xffffffdc2914eb90 [PAC] in panic (fmt=) at /mfs/mtkslt1092/mtk21026/CAS_REAL/alps-mp-s0_mp1 --2021_09_28_11_00/merged/kernel-5.10/kernel/panic.c:272 #7 0xffffffdc29c2eb78 [PAC] in sysrq_handle_crash (key=) at /mfs/mtkslt1092/mtk21026/CAS_REAL/alps-mp-s0_mp1 --2021_09_28_11_00/merged/kernel-5.10/drivers/tty/sysrq.c:158 #8 0xffffffdc29c2fab8 [PAC] in __handle_sysrq (key=99, check_mask=) at /mfs/mtkslt1092/mtk21026/CAS_REAL/alps-mp-s0_mp1 --2021_09_28_11_00/merged/kernel-5.10/drivers/tty/sysrq.c:602 This user mode backtrace as below is from [2]. (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 main2 () at cbreak.c:17 4 0x00000000004005b4 in main () at cbreak-3.c:10 > Could you please share more information about this problem? Why is > it > GDB needs to do things differently for a kernel mode and user mode > address? What is the test setup? Explanation is on the above. > > If we entered the above conditional block, that means DWARF has told > GDB > that LR is masked (ra_state_regnum), and so it needs to be unmasked. Yes, it needs to be 'unmangled'. However, kernel address and user mode address need different unmangle methods. > > Given this is generic AArch64 code, we don't want to risk breaking > existing use cases, and I'd like to understand what is not being > handled > properly. > I am not sure if changing code like this has risk or not. Need some gdb experts for review. Any suggestion and reviews are welcome. Thanks. :) > We have another gdbarch method that handles sign-extending kernel > mode > addresses (gdbarch_significant_addr_bit), but it is not clear if > that > could be used here without some examples. I think we cannot use significant bit when enable PAC feature. If enable PAC feature, we need to use bit[55] to know if address is in kernel address. (Can refer to [3]) [1] arm64: mask PAC bits of __builtin_return_address https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=689eae42afd7a916634146edca38463769969184 [2] AArch64 pauth: Indicate unmasked addresses in backtrace https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=3d31bc39e655ea39721754fa0ea539a8a0c9b26c [3] https://developer.arm.com/documentation/102433/0100/Return-oriented-programming Thanks, Kuan-Ying Lee > > Thanks, > Luis