From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id cwEhOcd0DmqfdAsAWB0awg (envelope-from ) for ; Wed, 20 May 2026 22:58:15 -0400 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=r7y4JwPI; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D4E521E098; Wed, 20 May 2026 22:58:15 -0400 (EDT) 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 vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (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 C1D001E062 for ; Wed, 20 May 2026 22:58:14 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 2A98F4B9209D for ; Thu, 21 May 2026 02:58:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2A98F4B9209D 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=r7y4JwPI Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) by sourceware.org (Postfix) with ESMTPS id 64CA14B92096 for ; Thu, 21 May 2026 02:57:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 64CA14B92096 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 64CA14B92096 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::a2c ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1779332268; cv=none; b=wsn+O4sN2D0bdVWBS0055p/gJh924IujeDaaXfDoP6fGL0J3kq5OhbqP1/OoMYg5pCxIFI/Okb5+9oesnaw3MEUys3kIiOGll9Ikarz4TbWh2kmEKJRgJk7LpOzYCygdTc21HlUkHwFl3K3mX/ohBm9FJS9bi7l2kKQePlm2Ufs= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1779332268; c=relaxed/simple; bh=euA00uNjFnsDKEG+LNmQIKfsUXth/SUaZGeAeRVUeEw=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=RKBwmWrYfP6vZzT1vJKGIe8j2JCeI5YOtU3d0heui4d8eGQck/mFokqdZb+MoCrjC2SB34mwQXNg/9poL+pdPa+pBUcONsmIkOjGah/Ijqc/LZapBExL0jIBdj2dMigXmXWaHl5UxWQCWgwt1KirjnoF6vHnd5y0wbWgeXCaIks= ARC-Authentication-Results: i=1; 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=r7y4JwPI DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 64CA14B92096 Received: by mail-vk1-xa2c.google.com with SMTP id 71dfb90a1353d-57512b86273so4114133e0c.3 for ; Wed, 20 May 2026 19:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1779332268; x=1779937068; darn=sourceware.org; h=content-transfer-encoding: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=2NPm26NZUtKkiNk3Tr1xbQhZbMQE0ZAjPsYHnLx7Yqk=; b=r7y4JwPI7L8IoLGyLTtbltPW8ClIL/Jm7CIfN+PWm97s5ZPApb9f2sT+FRNOWSmDEs UHkxUQ/SRnDLhuoe3cl5uwEtdsMBXQgXjY8PQwq/HwQtKvL5pARjpBvven1bB5VLLl5I gGqcs2Jv9NPDV/AWYTselMkiWCp3UjliXP8iTxC6+FolcZ4pEyw3fk7bp+XjytJ8a6wt 7vIfUsQbAz/8d8cPl092y0wDNJFbKHx0RpUzOHatoaenCKjvbsSOiKwssveS+cTQfwoz A1P47o2mNCmV2rHB5yJaB5NKxDo1IAwKItGasgExm32xk46H7BRVB+RHTQ7g8oAmWeUy Fidg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779332268; x=1779937068; h=content-transfer-encoding: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=2NPm26NZUtKkiNk3Tr1xbQhZbMQE0ZAjPsYHnLx7Yqk=; b=lRWnlLZAn2ASJW8dX2Ex/jzDhwpf95Y7tL5cn08Vst4DwrPTGLciDVNGlmgitmA5F7 zJYgf3yorWKXTyS/7897XzFO7Z1a7hvCCZKXqnjxYOa2sq1ZKOxgevfOgQurdqCj48H1 y/FVguaPfzO92m2/WGSpvRnkZooWnijP5dyhXL8C868ytH7kegAddRTGilpn3fzG56xp VPtTJNYpV1VqTK0n+hD8ZmPJIA0Bu308xX8qg0X/oVMczSOlIbVAhE3w6x8s2qCZeAF2 /tGw6P8T6G7kT4P+OERWB7IwJNZ1aQtIp4zpGxgcqvYD4bSUyY2pmOc5M4L6wq7Yzr+h rMAQ== X-Gm-Message-State: AOJu0Ywds7LwK3GLywp4vGcVLveATQLHuWp3cn5Fy2/xOnom/xzOeYey HwWZ8pGIWTIq9rxhG4nW09BjOsv60cLVv3waYY8pZ5hj+O6X+rvkskv1EobOs16E+dM6fAcshBi Sq4AW X-Gm-Gg: Acq92OEWamyopsVPljdL9NlrfJYCQL4z0WMcpAe56IBgppVk9O2uSiOGf8l5BfQjhyX dkYRHzyjQ2x4ski2JeWqQUDIH3FMD8cI7P3U+FRwQTg/btL+LZN311CSIXNVjtWrj0QzFQc6O4u ljajSgQv0IGQIQSiI7RLHTQdLiL4FORxUEJo1QRcMjNXFTJZmr13z5K7w/t/KctR6mUdSwR+WiL pgiwHZ/p8L2M7IguzPVVpD+26MzGRAYKLX0hH9acpiswCnA8fKcfAI4FmpQYUuVurRuyZM273q1 h9PxOs27JNwELs8OyQAFEPjQZ71qE29aHtf+b4nRTykCArG7Y9SaKA93Kyo9WBdBpIaoRnxmvSL TwOk8HfhosAIAGyJm7ModXUeVjkOolZ8/Z5dajHtD1KKWEe9EzToKUdD/OB/YrYyID+qn955iLQ e40OxhcduibPd51vmtZ7+OK2j7BP8Gz8xrVg== X-Received: by 2002:a05:6102:571b:b0:62f:46be:8318 with SMTP id ada2fe7eead31-6738c8ca10fmr786695137.6.1779332267700; Wed, 20 May 2026 19:57:47 -0700 (PDT) Received: from localhost ([2804:14d:7e39:8083:f04c:42e3:5943:38f6]) by smtp.gmail.com with ESMTPSA id a1e0cc1a2514c-95fc29cda8bsm11793474241.0.2026.05.20.19.57.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 May 2026 19:57:46 -0700 (PDT) From: Thiago Jung Bauermann To: "Schimpe, Christina" Cc: "gdb-patches@sourceware.org" Subject: Re: [PATCH v2 0/9] Add new command to print the shadow stack backtrace In-Reply-To: (Christina Schimpe's message of "Mon, 18 May 2026 10:10:32 +0000") References: <20260123080532.878738-1-christina.schimpe@intel.com> <87se8397qc.fsf@linaro.org> User-Agent: mu4e 1.14.1; emacs 30.2 Date: Wed, 20 May 2026 23:57:43 -0300 Message-ID: <87y0hdzcyg.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Donnerstag, 7. Mai 2026 06:14 >> To: Schimpe, Christina >> Cc: gdb-patches@sourceware.org >> Subject: Re: [PATCH v2 0/9] Add new command to print the shadow stack >> backtrace >>=20 >> > 3) For non-return addresses on the shadow stack, we want to display a >> > string, as already implemented for signals. For inferior calls, we >> > also want to display . The return address for >> > inferior calls is pushed onto the shadow stack by GDB, but we >> > currently don=E2=80=99t have a way to distinguish this address from no= rmal >> > return addresses. Thiago suggested pushing the return address >> > together with a marker, but it=E2=80=99s still unclear how this marker= should look >> like. >>=20 >> In AArch64 GCS, we can have "cap" entries which are markers in the stack. >> Bits 63-12 of the entry have to be the address of the cap entry itself, = but bits >> 11-0 can be arbitrary values. I think the equivalent in >> x86 shadow stacks would be an entry with the 63 bit set. Can the other b= its >> have an arbitrary value? >>=20 >> If so, before we push the return address for the inferior call, we could= push a >> cap entry / data entry with a magic value reserved for GDB to mark dummy >> shadow stack frames. Then GDB would know that the next entry after it >> would be the return address for the inferior call. >>=20 >> Then when printing a shadow stack frame, we can check whether the entry >> immediately preceding it has the magic value and print "> GDB>". > > In a different email I gave an update about this: > https://sourceware.org/pipermail/gdb-patches/2026-March/225486.html > This works without pushing anything on the shadow stack, so I'd prefer th= at solution. > Would you be ok with that? Yes, I agree it's a better solution. Glad you found it. >> The parts from your latest reply: >>=20 >> ---- >> >> 3. We can change GDB to also put a marker in the shadow stack when it >> >> does an inferior function call, and look for it in the shadow stack. >> > >> > We call shadow_stack_push in generic GDB code. Do you think we could >> > find an architecture independent marker ? >> > Then we can also return true with the gdbarch hook >> > is_no_return_address and set the string to . >>=20 >> I don't think we can find an arch independent marker. In x86, I believe = the >> marker would have to have bit 63 set. While in AArch64 bits 63-12 of the >> entry need to have the same value as the address of the entry itself. On= ly bits >> 11-0 of the entry are free to have an arbitrary token value. >>=20 >> > I am just not sure if the linux kernel ever decides to extend its >> > functionality for CET shadow stack and uses the bits that we use for o= ur >> marker. >> > In theory the linux kernel could decide to support 32bit shadow stack >> > for x86 one day, or supervisor shadow stacks =E2=80=93 and I am not su= re what >> > bits the kernel might set in the shadow stack elements to support this. >> > I wonder if we should discuss this in the linux kernel mailing lists. >>=20 >> Good idea, it makes sense to coordinate with the kernel people to see if= we >> can/should reserve a magic token/data value to use in GDB for dummy >> shadow stack frames. I'll ask the arm64 kernel people to see if they hav= e an >> opinion on the topic. > > With my proposed solution this is no longer necessary.=20 Nice! >> > 4) For signals, we also want to print , as in >> > the normal backtrace. Since in this case we have a normal return >> > address on the shadow stack, it=E2=80=99s not yet clear to me how to i= mplement >> this. >>=20 >> On AArch64, when calling a signal handler the kernel pushes a signal cap >> entry where bits 11-0 have the value 0. So to recognize the shadow stack >> entry which should be labelled "", we just need t= o look >> at the older entry and see if it's the signal cap entry. > > That one I solved now differently, too.=20 > With a bit refactoring I can reuse the "amd64_linux_sigtramp_p" function. > Do you have sth. similar for ARM? No but an AArch64 version can be created that would look for the signal cap that I mentioned, or alternatively (if I'm not mistaken) read the actual trampoline instructions in the inferior to recognize it. --=20 Thiago (he/him)