From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 5YxlBY8aGmmauwkAWB0awg (envelope-from ) for ; Sun, 16 Nov 2025 13:40:15 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=HECxBmTv; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 07CAB1E048; Sun, 16 Nov 2025 13:40:15 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from server2.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 ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C52191E048 for ; Sun, 16 Nov 2025 13:40:10 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3B6FE3858C52 for ; Sun, 16 Nov 2025 18:40:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3B6FE3858C52 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=linaro.org header.i=@linaro.org header.a=rsa-sha256 header.s=google header.b=HECxBmTv Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id C47BB3858D20 for ; Sun, 16 Nov 2025 18:39:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C47BB3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C47BB3858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::434 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763318371; cv=none; b=iHvOQ4w3RJGucqJq/8kK0l0RsQBr+mTg0xGSs8Cm0kOE2EYCsWKYA7xgkopcaUQrzXUnFAzPIN9/BFcLyqXKNryfqnuzL34iTqqvfbzQRn8RFH3+7KGQ7GGGzqyNqaa3gZ6hx2e351re7ExZhEplk5kScaY5A0RzBk1L2ptqmrU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763318371; c=relaxed/simple; bh=Vv8TYFvFAcZZBz+AH6BnoAU7UtTBTmHWIh3h/O1SwOs=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=mZlPVCYAEix2rGKUSzrLYv+YDZ04W5z2BrYPzVasEOyUbHtPMBNpaNj1H55EChg1kjkRNKJQ6eU3D2XJonFyB1TJI1RiNbC1QnrUoYYBjFsruQ6pAoYPnw2AVidOHVHwSO3zguLjiOw4QGdx4X1eR4Na/mDh87wf+9/fFTpOnoI= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C47BB3858D20 Received: by mail-pf1-x434.google.com with SMTP id d2e1a72fcca58-7bc0cd6a13aso1648783b3a.0 for ; Sun, 16 Nov 2025 10:39:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1763318370; x=1763923170; darn=sourceware.org; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=2lu14MNDjt+q32FsPZ6O8NvFybCsWLSroJG993yUDi0=; b=HECxBmTvbqqfIWpQ5i5BZlurA/h1hkLufWRiR/wRIERfCfMYEwqxe3wLWcQxSVLfJG /yEehSqlVo17rwZbZgMQzGxIjFxs83eDf1qN59+9oejQcQUqRmMfNE3dbPgQuphRN0hI GweUOSiUJ5anzukheWBn46lQVcL+prhT4UwMWyjt9BO+w44M/K3yRZwDwLVmuIR0X58c OygUbSFy2ZEUa/HMEacPtxPV8oEBmGLYrK443zMFLmp9qDPR7F0wvkwNSKo454EiGZBW L5cY/TXQa0/QLq2bjwT8VBAXrMRPC6kuH0/iqru/MNgwP/tTRNCWIJTp8XQTLnCf4Myo duZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763318370; x=1763923170; h=mime-version:message-id:date:user-agent:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=2lu14MNDjt+q32FsPZ6O8NvFybCsWLSroJG993yUDi0=; b=usqJFBqjzIWhTOh8d9Y9lxDkRnT8SEqtjU/oUqXWSbiZWS6oz0xyY8l8/5Q+uJYaKH F7ni45U1dY62w6Nc1RGtJMC4MfO5IOnPEi3wZbbSD9KLI733Q2R/wWoBPgnPCcAr5JBr cIVWV4YfKF/prKxb5aWIV/Y65fAkvJ2B1jrsyockDMEO8vK4pcgBXrc5O24XUqGZoV9F MMKu3LaSFadZc2f6hz1xqmIgqbaYzwiJvoN82mZK0Zw+ZRVtkNJwwnCRb0/qtUxYYT3M 9xKsFP4Ynrk591S8TgC1gJeF4duzESL8BVJ5ybWqKQ4KVbEXiyddVwecMGIJEUMh1I5A PIzA== X-Forwarded-Encrypted: i=1; AJvYcCVKSJo2dhezNIcfycJOGe28XORBlbfcKVyMP04bt53hDDbQRJS2VPoP4bKjLrruZdOFw5iS4D66Hp1Tww==@sourceware.org X-Gm-Message-State: AOJu0YxEQ16Ay5dW5/bcER6UjQJSrGxWYTjuyJdg+ZiHOpd9+eQrruD9 DfPb/j/Q2rck0WDn8bJqBywjagptp4Z/bZuOiYbLeYMBay+3ee0H5XZyvuid4NJmeKY= X-Gm-Gg: ASbGncvqDrrO9xc2lbm+WovKBNdrii3nGnUbT1erZuL/3uSDSVcxsB1jhmQSI7oQ0pz Spm+4WjMnrOuMJsUoyitY6MC4MLNqiZ74kG/PkSCmokW44R9ezQMiHPdn6uMhRMFm/SLEjgd7f2 YDzbufOeR7l1YeMT/b1TDdCae1tx9IudPL0c8R9wZqksD1o5+x1GEBoGohXKiwzr5X1bvZyyq+r i8Ev6R+Elcr+li1nW1ZyQuiGT8UkvDBGJM+pmntnPD+uTJE1nU/4NQQkElppu4mKWZBZyq0QguH cMC8tgBL8iqGBvTS9FOvc928wOETVugKfBYmxz8tRMW6ARNrGnQBjQ1VMnX+9ZwyFP10FAxxgLz df02HbpSqbKYZuqftsGIjL2oCgzs+1hF4pPCbAmfPrR8zk82zkIu66uveDm4G9B2E1kyhbkSj19 UTBqmrpSO27vHBkYW0rYZK X-Google-Smtp-Source: AGHT+IGzNV7+B/C1xQMkC688SlG26Un1W5VMF/1La/DyVgWQiy/LbIS684rSi/beSkeUg6fAoZJ+qw== X-Received: by 2002:a05:7022:787:b0:119:e569:f851 with SMTP id a92af1059eb24-11b033ae680mr3970344c88.8.1763318369566; Sun, 16 Nov 2025 10:39:29 -0800 (PST) Received: from localhost ([2804:14d:7e39:8083:e81a:b251:5b81:f3c8]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2a49d695821sm42384532eec.0.2025.11.16.10.39.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Nov 2025 10:39:29 -0800 (PST) From: Thiago Jung Bauermann To: "Schimpe, Christina" Cc: Eli Zaretskii , "gdb-patches@sourceware.org" Subject: Re: [PATCH 7/9] gdb: Provide gdbarch hook to distinguish shadow stack backtrace elements. In-Reply-To: (Christina Schimpe's message of "Wed, 12 Nov 2025 17:28:39 +0000") References: <20250923111842.4091694-1-christina.schimpe@intel.com> <20250923111842.4091694-8-christina.schimpe@intel.com> <86wm5pcrs0.fsf@gnu.org> <87cy60p1x9.fsf@linaro.org> User-Agent: mu4e 1.12.13; emacs 30.2 Date: Sun, 16 Nov 2025 15:39:26 -0300 Message-ID: <87o6p1x1nl.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hello Christina, "Schimpe, Christina" writes: >> -----Original Message----- >> From: Thiago Jung Bauermann >> Sent: Sonntag, 2. November 2025 22:20 >> To: Schimpe, Christina >> Cc: Eli Zaretskii ; gdb-patches@sourceware.org >> Subject: Re: [PATCH 7/9] gdb: Provide gdbarch hook to distinguish shadow >> stack backtrace elements. >> >> "Schimpe, Christina" writes: >> >> >> -----Original Message----- >> >> From: Eli Zaretskii >> >> Sent: Tuesday, September 23, 2025 1:50 PM >> >> To: Schimpe, Christina >> >> Cc: gdb-patches@sourceware.org >> >> Subject: Re: [PATCH 7/9] gdb: Provide gdbarch hook to distinguish >> >> shadow stack backtrace elements. >> >> >> >> > From: Christina Schimpe >> >> > Date: Tue, 23 Sep 2025 11:18:40 +0000 >> >> > >> >> > On x86 with CET there can be elements on the shadow stack which are >> >> > not return addresses. In this case, we just want to print the >> >> > element itself in the shadow stack backtrace, but no further information. >> >> > >> >> > Provide a gdbarch hook to distinguish between return and non-return >> >> > addresses and use it to print the shadow stack backtrace as >> >> > described above. >> >> > --- >> >> > gdb/doc/gdb.texinfo | 19 ++++++++++++ >> >> > gdb/gdbarch-gen.c | 32 ++++++++++++++++++++ >> >> > gdb/gdbarch-gen.h | 15 +++++++++ >> >> > gdb/gdbarch.h | 1 + >> >> > gdb/gdbarch_components.py | 17 +++++++++++ >> >> > gdb/shadow-stack.c | 64 +++++++++++++++++---------------------- >> >> > gdb/shadow-stack.h | 37 ++++++++++++++++++++++ >> >> > 7 files changed, 148 insertions(+), 37 deletions(-) >> >> >> >> Thanks. >> >> >> >> > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index >> >> > ebda4546b58..a0fde385a8e 100644 >> >> > --- a/gdb/doc/gdb.texinfo >> >> > +++ b/gdb/doc/gdb.texinfo >> >> > @@ -8887,6 +8887,25 @@ This is how a shadow stack backtrace looks >> >> > like >> >> on amd64: >> >> > @end group >> >> > @end smallexample >> >> > >> >> > +There can be elements on the shadow stack which are not return >> >> > +addresses, for example on x86 with the Intel Control-Flow >> >> > +Enforcement Technology (@xref{CET}). In case of signals, the old >> >> > +shadow stack pointer is pushed >> >> ^ >> >> A cross-reference is missing here. >> > >> > Thanks will fix. >> > >> >> > +in a special format with bit 63 set. For such shadow stack >> >> > +elements, the shadow stack frame just contains the level and the >> >> > +address on the shadow stack, as shown in the following example by frame 1: >> >> > + >> >> > +@smallexample >> >> > +@group >> >> > +(gdb) bt shadow 4 >> >> > +#0 0x00007ffff7c54d90 in __restore_rt from /lib64/libc.so.6 >> >> > +#1 0x80007ffff79fffd8 >> >> > +#2 0x00007ffff7c54ce6 in __GI_raise at >> >> > +../sysdeps/posix/raise.c:27 >> >> > +#3 0x000000000040115d in main at /tmp/amd64-shadow-stack-signal.c:32 >> >> > +(More shadow stack frames follow...) @end group @end smallexample >> >> >> >> Would it make sense to show something like "", instead >> >> of a frame with only an address? >> > >> > Yeah, this is a good idea, I wondered about a similar thing actually >> > but wanted to discuss the general direction for handling those specific >> > elements on the shadow stack first. >> > Maybe there are more options on other architectures that we have to >> > consider. >> > Let's wait for more feedback on this, I added Thiago again in cc here. >> >> Yes, I would like to show a "" message in the >> corresponding shadow stack entry, as is done in the regular stack: >> >> (gdb) bt >> #0 handler (signo=10) at aarch64-gcs-signal.c:59 >> #1 >> #2 __pthread_kill_implementation (threadid=281474842447584, >> signo=signo@entry=10, no_tid=no_tid@entry=0) >> at ./nptl/pthread_kill.c:44 >> #3 0x0000fffff7e77670 in __pthread_kill_internal (signo=10, >> threadid=) at ./nptl/pthread_kill.c:78 >> #4 0x0000fffff7e2cb3c in __GI_raise (sig=10) at ../sysdeps/posix/raise.c:26 >> #5 0x0000aaaaaaaa0b24 in main () at aarch64-gcs-signal.c:96 >> >> Here is the corresponding GCS backtrace: >> >> (gdb) bt shadow >> #0 0x0000fffff7ffa85c in __kernel_rt_sigreturn >> #1 0x0000fffff7bff000 in ?? >> #2 0x0000fffff7e2cb3c in __GI_raise at ../sysdeps/posix/raise.c:27 >> #3 0x0000aaaaaaaa0b24 in main at aarch64-gcs-signal.c:99 >> >> In this example "" message would replace the VDSO >> function name in entry #0. Also note that it's an actual return address but we >> still want to show a custom message for it. >> Finally, notice that there's GCS entry #1, which isn't a return address. It's a "cap >> record", which marks that the stack is currently not in use. When a signal is >> delivered, the kernel pushes two entries to the thread's GCS: first the cap >> record, then the address to the signal trampoline (__kernel_rt_sigreturn). For >> this entry, I'd like to show "". >> One suggestion to handle that is to make do_print_shadow_stack_frame_info >> call a new hook gdbarch_print_shadow_stack_frame_info which would allow >> the architecture to print the shadow stack frame however it wants. If the hook >> returns false, then do_print_shadow_stack_frame_info would print the >> information itself, as it does in your patch. What do you think? > > If possible, I'd like to keep it as generic as possible. The > message is useful for CET, too. The CET equivalent for "cap record" should be "sigframe > token". > > |1...old SSP| - Pointer to old pre-signal ssp in sigframe token format > (bit 63 set to 1) > (https://docs.kernel.org/next/x86/shstk.html) Agreed, it should be as generic as possible. > In the commit message I described that "bt shadow" always prints the address: > > "Similar to the ordinary backtrace command 'bt shadow' can be configured > using COUNT and the command line option -frame-info. However, we always > print the address and the command is not affected by the setting > "print address" as well as the setting "print frame-info location-and-address". > Also we do not print the frame arguments." > > Do you think we should align with the ordinary backtrace for the printing of shadow stack > addresses ? > When implementing this I thought it would be nice to always print addresses, but now I am > not so sure anymore. I understand why it makes sense to ignore the "print address" setting: essentially the only things the shadow stack contains are return addresses, and we're not going to print them? My inclination is to agree with always printing them. But thinking a bit more about it, the frame information that GDB prints is good even if the address isn't printed along with it so I think it's better to respect the setting. Also it's good to be consistent with the regular backtrace output. > Based on your suggestion we could print it as follows and replace the shadow stack > addresses: > > (gdb) bt shadow > #0 > #1 > #2 0x00007ffff7c4527e in __GI_raise at ../sysdeps/posix/raise.c:27 > #3 0x0000555555555175 in main at /tmp/amd64-shadow-stack-signal.c:30 > #4 0x00007ffff7c2a1ca in __libc_start_call_main at > ../sysdeps/nptl/libc_start_call_main.h:74 > #5 0x00007ffff7c2a28b in __libc_start_main_impl at ../csu/libc-start.c:128 > #6 0x0000555555555085 in _start > > For GCS we show "cap record" instead of "sigframe token". I agree. I like the output above. My only comment is that there a also the "set backtrace past-main" and "set backtrace past-entry" options, which "bt shadow" should also respect. So if the former setting is on, the output above should stop at frame #3. > In case the gdbarch hook "is_no_return_address" returns true, we could additionally return > a string, > which should be displayed inside the <...>. So in our case this would be "sigframe token" > or "cap record" . > > What do you think? I think that is a good idea, and should be enough for GCS. -- Thiago