From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id a6YJI5/Ag2WcViYAWB0awg (envelope-from ) for ; Wed, 20 Dec 2023 23:35:43 -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=Rgdd/mUr; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 8549A1E0C3; Wed, 20 Dec 2023 23:35:43 -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 722F01E091 for ; Wed, 20 Dec 2023 23:35:41 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D83103861856 for ; Thu, 21 Dec 2023 04:35:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D83103861856 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1703133340; bh=B5uGSUI8vaCh9lx1CLT52A0UFi7jI29PX9WtVoIpk4I=; 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=Rgdd/mUrAuShKHeewOAZKACZmIEkoARh7AP3GvOdVsIDzUy7daf52ASHSW1sl9k+3 scaImI975Hfu8y48a/Ie8yFm6RlikY1spVBRB56baMr/RmpxaqUXqDwMGKrxMRISsO YOS1ubbfQUXNytFBbujoaHNTIIMaX7A8Az0lHVec= Received: from mail-yw1-x112f.google.com (mail-yw1-x112f.google.com [IPv6:2607:f8b0:4864:20::112f]) by sourceware.org (Postfix) with ESMTPS id AF1703858286 for ; Thu, 21 Dec 2023 04:35:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AF1703858286 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AF1703858286 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703133316; cv=none; b=wB79hYVl1CypPpOyCl3x3URLlIR2L5tnCZXQa7bKqvsac0D1ICV7t7b+ZPRsRrFohg/6XVhmvyUPG/f/HtbWviDjv1SgkeEqc8n0jTKpMnaH5jU4ClX7Q004hEThT/CPtL9uy+smDy5rknCePNvo6S9+7K3ObWA7yoR1Qtzqpgw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703133316; c=relaxed/simple; bh=B5uGSUI8vaCh9lx1CLT52A0UFi7jI29PX9WtVoIpk4I=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=FQbPl1Z8qX5Xj8dcfxExg3doPWXMfhigAsXRBj32sYAejMRcoWJMH/bl0Qck7Vsl221osXhd51uuw055/LFBHGBwkDxtDYH7eg9Q8upkke13sCPq0s4VdxX3q0vQdWEVOdmLpR85Gxccm+uXw+0PF68YySLlNvkc4KQ5ZsQntjc= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-yw1-x112f.google.com with SMTP id 00721157ae682-5e7f0bf46a2so4393727b3.1 for ; Wed, 20 Dec 2023 20:35:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703133313; x=1703738113; h=content-transfer-encoding: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=B5uGSUI8vaCh9lx1CLT52A0UFi7jI29PX9WtVoIpk4I=; b=O6RoXzRSBjrPOqIGVb+X0pt0vTRSwzZ5G4VMtv6eZoX8D4KEsb7b3ihai0RG8lyu4w JTYwL7YZiaqBKdxoocGsepzgLoO0ZtN6bd9FrFJWlUA+0XDm1nGK9WnmzwCh8wDH/0rA b+YDGS5yvsXSbQ1yol55zv0qBqKCi7ue0ODxtLm6RwIIqJ2FRhtxHDY52+ao56yNECR7 8A7evDMBdZZEI5bScKjmaNtbPdKQo2/+RJoPnqyLTpRf1LrgboPpWisPxPIpvIjD7cAX r9tKjh0YimuXorQGVbE0TfSbT33g1fdGhm0z4RZ4jlk1dZ8CVXRFAj3y8GPUmVi4tO4j 6NPw== X-Gm-Message-State: AOJu0Yxp0l+tldsyKLE8RWCI0/gAeTP7Cs/AGrs4lcUZFnC/2gsCzr+H BKov3wHxQtOyDzjzG9z9bBUa7Qox6mpGzAJMl8J/iw== X-Google-Smtp-Source: AGHT+IG74A9X5qJROLfqqfRvwGhT7ONCiZKzQ9dBbqfdSvQm+4EzyPUicV+ijhB/wMy0AjH5DixlUA== X-Received: by 2002:a0d:db56:0:b0:5e4:6349:5f56 with SMTP id d83-20020a0ddb56000000b005e463495f56mr905778ywe.7.1703133313037; Wed, 20 Dec 2023 20:35:13 -0800 (PST) Received: from localhost ([2804:14d:7e39:8470:fc6a:8479:3ec4:6bb]) by smtp.gmail.com with ESMTPSA id jg13-20020a17090326cd00b001d398876f5esm561289plb.121.2023.12.20.20.35.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Dec 2023 20:35:12 -0800 (PST) References: <0dc1193d-83dc-4433-9f2b-25f3d1bb42fd@arm.com> User-agent: mu4e 1.10.8; emacs 29.1 To: Luis Machado Cc: "Schimpe, Christina" , "gdb@sourceware.org" Subject: Re: Shadow stack backtrace command name In-reply-to: Date: Thu, 21 Dec 2023 01:35:09 -0300 Message-ID: <87zfy4fa0y.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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" Hello, Luis Machado writes: > Hi, > > On 12/20/23 15:35, Schimpe, Christina wrote: >> Hi,=20 >>=20 >> Thanks a lot for your feedback. Please find my answers to your comments = below. >>=20 >>>> Having in mind that that the shadow stack is not only a x86-specific >>>> feature but can be seen as a generic concept we also considered that >>>> it could be part of the existing backtrace command, e.g.: >>>> - "bt -shadow" >>>> (+) Short syntax >>>> (+/-) Most of the settings of the bt command don't apply to the shadow >>>> stack (frame arguments and info). This might cause confusion. >>>> >>>> For this option, it might make sense to introduce a new setting for >>>> the bt command which is for shadow stack only, e.g. "-symbol-filename >>> [on|off]". >>>> >>>> What are your thoughts on this topic? Any feedback and new ideas are >>> welcome. >>> >>> I like the option of reusing whatever is possible to reuse from the cur= rent >>> backtrace command, so "bt -shadow" seems like a sensible option. I like it too. >>> It doesn't seem to me like this command will be used a lot. I expect it= will be >>> useful only when we catch a fault due to a corrupt stack trace, so putt= ing it within >>> the more general "backtrace" option would accomplish that. >>> >>> With that said, depending on how shadow stack support is implemented in= gdb, I >>> expect gdb will automatically validate the stack trace against the shad= ow stack >>> (maybe on a fault), and complain if they go out of sync. Does that sound >>> reasonable? Maybe even display where the flow veered off course. >>=20 >> No, we don't plan to validate the stack trace in GDB, as we don't see mu= ch >> additional value for the user. >> In case of a CET violation the user will see a SEGV with CP specific=20 >> si_code =3D 10 (SEGV_CPERR). Printing siginfo will help to find out the = reason for SEGV. >> Inspecting the shadow stack and normal bt will show where the traces got= out of sync. > > Thanks for clarifying it. My understanding is that aarch64 will also use = SEGV_CPERR for > the GCS faults, so it will be in sync with CET regarding reporting. Yes, that is true. >>> AArch64 will have a counterpart of this, with the Guarded Control Stack= (GCS) >>> feature, so the more generic we make this, the better. >>=20 >> Would the option's name "-shadow" be suitable for the GCS? I find it dif= ficult to come >> up with a more generic name that would cover both. > > From this entry [1], looks like the term shadow stack is a reasonably gen= eric way to refer > to this feature. So I think it is a suitable name, and would work for GCS= as well. > > [1] https://en.wikipedia.org/wiki/Shadow_stack Yes, the Linux kernel patch series adding support for GCS=C2=B9 plugs into generic code that uses the "shadow stack" terminology. E.g., AArch64 programs will call "prctl(PR_SET_SHADOW_STACK_STATUS, PR_SHADOW_STACK_ENABL= E)" to enable GCS, "map_shadow_stack()" to map it, etc. So that name will already be familiar to programmers debugging an app using GCS. PS: FWIW, I'm in the middle of adding GCS support in GDB. --=20 Thiago =C2=B9 https://lore.kernel.org/linux-arm-kernel/20231122-arm64-gcs-v7-0-201= c483bd775@kernel.org/