From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id UBQWJQn1d2EvYgAAWB0awg (envelope-from ) for ; Tue, 26 Oct 2021 08:31:05 -0400 Received: by simark.ca (Postfix, from userid 112) id 827E01F0BF; Tue, 26 Oct 2021 08:31:05 -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.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_DYNAMIC, 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 2B5E21EDDB for ; Tue, 26 Oct 2021 08:31:04 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BCA34385801F for ; Tue, 26 Oct 2021 12:31:03 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BCA34385801F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1635251463; bh=cdisy9R77YCqGPElJUP5/Q3ZzrfHLIvxjIbdsBzbEbg=; 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=IFnEuJcioTb3RlgoT6HFH2nOPhgsDnc4ifZzk9BvDsEQnuMUU1jX1b9+pexj+Qf07 ec3Bo6hB/CIiICGONIwmUxntiBux6McBzL8yldSfa49xGwLUoVGtKseT6YLchEVUSM RUrxNFs32KPkznT5YOS8fRxI5Ly+Sv4QN+tBbzU0= Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) by sourceware.org (Postfix) with ESMTPS id 6D5683858C27 for ; Tue, 26 Oct 2021 12:30:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6D5683858C27 Received: by mail-oi1-x22e.google.com with SMTP id t4so20305440oie.5 for ; Tue, 26 Oct 2021 05:30:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=cdisy9R77YCqGPElJUP5/Q3ZzrfHLIvxjIbdsBzbEbg=; b=S2G+IapW+cguv2JXsqCZlUv116UZKE/iNUSWw3Uw5Uk258jnJjkPa0Tf/K4xjdWBjp SEs8mBe1UoEDQVVJrByqcwsH/bTtCgOExDLAJ9qIaB2iiFboQFryc6dwWZJWKorJ2Il2 rKsKQdv5N7prk4PJTxi4V5rvWO20eDfiaAILONmglxO/GGFTcttQhMcvdH9JyLDdAFfq XOc9/PoEY3Y40APmMQ1uFDles1PEgz1N6+6nfzmRh10m6lnPE7wZ+K+14Zlpjzh1B5A4 qMVGRKVaPAa3Id1EjPBEGEZ/eV8K7X/gPCPTEPXD9p+4sPNtiSTAQYh9Jjo1nPyAQshg WDFQ== X-Gm-Message-State: AOAM532rGOTlGWWEqyH81Tw80O0sfLFN6XwAU9UoTIDW0ILxKHH1WkW6 LQvCz+v6n4HrNMR2TsfoeFh1ew== X-Google-Smtp-Source: ABdhPJyawzOQ1Md6ajtNFww5cTwrtxy3goNYlO39AzEWPIDWhDUOc4IFRAJV2KIsY4t15g2dth+kEg== X-Received: by 2002:aca:bf06:: with SMTP id p6mr27744946oif.42.1635251443666; Tue, 26 Oct 2021 05:30:43 -0700 (PDT) Received: from ?IPv6:2804:7f0:4841:3c03:7012:cad0:f2ca:8851? ([2804:7f0:4841:3c03:7012:cad0:f2ca:8851]) by smtp.gmail.com with ESMTPSA id i42sm4406020ota.43.2021.10.26.05.30.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 26 Oct 2021 05:30:43 -0700 (PDT) Subject: Re: [PATCH] AArch64 pauth: Indicate addresses in backtrace for kernel To: Kuan-Ying Lee , "gdb-patches@sourceware.org" References: <20211025114705.32548-1-Kuan-Ying.Lee@mediatek.com> <17ca411d3caeb54bbe6535676c12e8dc61a0f2d2.camel@mediatek.com> Message-ID: <98c133b4-81f9-35ec-93dc-9de2e017af3d@linaro.org> Date: Tue, 26 Oct 2021 09:30:39 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <17ca411d3caeb54bbe6535676c12e8dc61a0f2d2.camel@mediatek.com> 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: =?UTF-8?B?SmFtZXMgSHN1ICjlvpDmhbbolrAp?= , =?UTF-8?B?TmljaG9sYXMgVGFuZyAo6YSt56em6LydKQ==?= , =?UTF-8?B?WmhpeW9uZyBXYW5nICjnjovlv5fli4cp?= , =?UTF-8?B?Q2hpbndlbiBDaGFuZyAo5by16Yym5paHKQ==?= Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi, On 10/26/21 9:22 AM, Kuan-Ying Lee wrote: > 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. No problem. That part was OK. > > 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. Thanks for the explanation. That makes sense now, and the current code is only handling usermode addresses. I was slightly confused with bit 55, but I see it is a VA range select bit. > > 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= out>) > 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= out>, val=, v=, nr_to_call= out>, > 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= out>, val=, v=, nr_to_call= out>, > 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= out>) > 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. That's what I'm trying to assess with your help. I'll go through the patch once again with a better understanding of your use case. > > 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 > > >