From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6hbaBS/4jWWzJS0AWB0awg (envelope-from ) for ; Thu, 28 Dec 2023 17:35:27 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=fu8xhzTG; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 0C8901E0C3; Thu, 28 Dec 2023 17:35:27 -0500 (EST) 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 F16C61E0AC for ; Thu, 28 Dec 2023 17:35:24 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5C0983858C2C for ; Thu, 28 Dec 2023 22:35:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5C0983858C2C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1703802924; bh=qN5v1419GhToPBgx2xvet4ZtQfXhshcU8KjtN/b3hrM=; h=References:To:Cc:Subject:In-reply-to:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=fu8xhzTG3bcI+TLqiUO+RKcZRLZu/kUR1MjqavadTfJ3c8IMPxEcpYnkYKkuu7PEE vQm+8WklpykuwRvInhEF+ZuCegqgjVO3rIUTmDxknAlewFays17qTwCYpnVSw2JJIY 0k7cLWrKci+ioSn3z+fGVHtq/wOKlra8Eja3q9jc= Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id 2194C3858D28 for ; Thu, 28 Dec 2023 22:34:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2194C3858D28 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2194C3858D28 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703802866; cv=none; b=a0cTtgVcZO7U9yMTx2NUpRkDBWuyn0HaYVaCvG4jRuOn2XVu6KmB5Pi8ZBZ9KE0tyTPUAkuJO9UvZD/D00Hq/KJchGE/PCA2r5OyFFe3JuaUyfXXHUB6A8xaQSHPKHWN69fReIMk/aGWypn6iHllk0UIAwBCE+k3gd/vcTH6scE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703802866; c=relaxed/simple; bh=qN4DnAaonX6vxcbtE7ejOkxoXCT4TogWQ+aRKqbLxnA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=qWJUTL82ONxC7JD0WhVZJDBexv+l34Sag3JGALdlkwnXSo3lY8zyM3aNmrkyD7qsA1YHctcp+mnliCpEUJyWQyY2sCbZKzTx4WzEMOYHbtZgyWOaxL2N43mJH6yMvBjJBR6CFeqp9BhQxgZDeDqsEZEtFZdK+J/R5EFLcauns78= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pg1-x536.google.com with SMTP id 41be03b00d2f7-5c21e185df5so4864145a12.1 for ; Thu, 28 Dec 2023 14:34:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703802850; x=1704407650; h=mime-version:message-id:date:in-reply-to:subject:cc:to:from :user-agent:references:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qN5v1419GhToPBgx2xvet4ZtQfXhshcU8KjtN/b3hrM=; b=WoyQvara4/jCiK8LblYRhXAuH1pmeDguKr2iQ7lBWK0E2FO/W7cCEC/jFCv5H/mW7Y 1bsSBvDIuzLa6Yb4V4kkaIQhjiX6U1FTpk0OGMwasLA2Nayd+be/LbFB2K2CsIzTQRhD 8kXIiAb2M0Axekg+z6fWLhWc0I0ZpHnj5FF9SbPFL3I7jILsSqVu0bIYyOLO+h4Ld2lu 22YXexCqxw8Ym/LVfqCSFRADN/gVUa9JggaPOzq2t8JKgmekX9svexAFVv3293staKtR L7KmVcxTXbF+64CrYV67TMd/RHRaxwzM+SUYlfSMVMXbzqW1ykeGwFlUS/5BwE976Lle 82+A== X-Gm-Message-State: AOJu0YzfeUBCcBeFuMLGCxFGg9dKe55SnWF+JNIrTj2ZBRHVX5sHO8pI r39QV3JNYazljcsmZueAPo+m+llnXfZp1w== X-Google-Smtp-Source: AGHT+IGswuTUpXeFYbHWTwPp6p+wCYF1FbY/O1YdXWwo2F/R3H9xc+esF8Mby+us8N9v9gulxhgmnQ== X-Received: by 2002:a17:902:e806:b0:1d4:463c:ac2 with SMTP id u6-20020a170902e80600b001d4463c0ac2mr8820684plg.42.1703802850055; Thu, 28 Dec 2023 14:34:10 -0800 (PST) Received: from localhost ([2804:14d:7e39:8470:4a0f:b1d8:5ddf:caee]) by smtp.gmail.com with ESMTPSA id h13-20020a170902680d00b001d05433d402sm14789378plk.148.2023.12.28.14.34.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 Dec 2023 14:34:09 -0800 (PST) References: <87a5q0eq34.fsf@tromey.com> User-agent: mu4e 1.10.8; emacs 29.1 To: Tom Tromey Cc: "Schimpe, Christina" , gdb@sourceware.org Subject: Re: Shadow stack backtrace command name In-reply-to: <87a5q0eq34.fsf@tromey.com> Date: Thu, 28 Dec 2023 19:34:07 -0300 Message-ID: <871qb6c5y8.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Thiago Jung Bauermann via Gdb Reply-To: Thiago Jung Bauermann Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" Tom Tromey writes: >>>>>> Schimpe, Christina via Gdb writes: > >> A shadow stack is a second stack for a program introduced in the Intel (R) >> Control-Flow Enforcement Technology (CET). The shadow stack is used for >> control transfer operations to store the return addresses. > > One question I had is when, as a gdb user, would I want to see this > information? I think the most common shadow stack error a GDB user would encounter would be when the inferior is returning from a function and gets a SIGSEGV because the return address is wrong (e.g., because a buffer overflow wrote over it). There are other possibilities, for example a program can create different shadow stacks and switch between them (e.g., when it implements userspace-level threading) so some error could happen during that process. E.g., in AArch64's Guarded Control Stacks, there needs to be a special "cap" value at the end of the incoming stack and a SIGSEGV is generated if that's not the case. In this case I think the user would want to be able to direct the shadow stack backtrace command to print the backtrace of that other stack, instead of the currently active one. Another example would be trying to write to a mapped shadow stack that is read-only. That also causes a SIGSEGV. Though not sure if the shadow stack backtrace is relevant in this scenario. >> It is configurable using "print symbol-filename" and COUNT. >> The command can be called by the following names: >> - "info shadow-stack bt", "info shadow-stack backtrace" > > Like others in the thread, I'm -1 on "info" as a prefix. > I liked "bt -shadow", but I was also wondering if the information should > just be integrated into the ordinary backtrace when available... that's > why I'm wondering when I'd want to see this. In my first example, it would be useful if the regular backtrace output noted where it differs from the shadow stack. Though I think a way to see the shadow stack backtrace by itself would still be useful. -- Thiago