From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id cAD5Ok7JgmWaoCUAWB0awg (envelope-from ) for ; Wed, 20 Dec 2023 06:00:30 -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=CsVJEkST; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id E145D1E0C3; Wed, 20 Dec 2023 06:00:30 -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 D24851E091 for ; Wed, 20 Dec 2023 06:00:28 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 411A63860C2C for ; Wed, 20 Dec 2023 11:00:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 411A63860C2C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1703070028; bh=ZXMq0NnEM9WWW8jE34mZ4jqngXTgmm//X8ZfqLe09O4=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=CsVJEkSTrnuzsbX4BhplbLnTTVl6YhZpeviUuwddtUUfFrRxf3IKHodDIFYoxDqo8 Eq1qGVuAvKTzy7S3SQBM/tYlBnHfQ7qQA7CbfOFRIPjHZUndNkfveYFK/9cqti/8d4 uTOxq4YRdOLpPYRdY89VFB9PvP9cgbxOBOlEgs5U= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 5A682386181B for ; Wed, 20 Dec 2023 10:59:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5A682386181B ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5A682386181B ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703070001; cv=none; b=toHLFVgjAA+7sp2AeUll8Gj6+NycDZllJ5BWsN9ppprS/IDFkE3O1pxpKdgEDxqq+SRhBfsyHWvl3d1907tB5xkH/+vQAdFxMrs8WnSAHBm4LIcVKXHyAw6Xm5uGUQtz+udsqECYdy40FEsrCFL4Y1W72OoIMiCo7gWM26WzrJ4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703070001; c=relaxed/simple; bh=p0U1pjaXnnB3ahcbrMBld8Ho/nx1WAs2h6JUY833FNA=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=Lu3eFfkKMb3/wz3Z0xa+dKdMBsE744eBXU472p1/gddAdvHQnyHETttvXfpqtGfLxDw827bsJ5Bz95f1OpoZfdSpjx5Ti4vdlXAHXmKPVMIsJCke/z8K4tBw06b9VNGMOwGYmuDU3+W1oLe4el8XoEAyUzU2pZBCwekFod68W0M= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from mail-ej1-f71.google.com (mail-ej1-f71.google.com [209.85.218.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-570-iEXIK89ePguYte0hdFYGLQ-1; Wed, 20 Dec 2023 05:59:57 -0500 X-MC-Unique: iEXIK89ePguYte0hdFYGLQ-1 Received: by mail-ej1-f71.google.com with SMTP id a640c23a62f3a-a1da829c653so299000566b.3 for ; Wed, 20 Dec 2023 02:59:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703069996; x=1703674796; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZXMq0NnEM9WWW8jE34mZ4jqngXTgmm//X8ZfqLe09O4=; b=Wu5AQcw/Jg4pCGoE7QUdVWbbFaswMIHs2nkX20zRAQqYExTeLhHLuCBcI1xNlm2YfL DqndfqSs1V8aRx7gxCGGALowzCLia+hVBiU0bzmeV+ASORPhrv8Q5VgTC9QjP04LrAn/ nidHbzvxY5trDVxa2C/d7HsmEbMMu1AUOwjjSg70/qHPmbDPbI74up9HRmTMvIh/f6a4 rMKjjXKwggemX1aWEIZRGDe6SSrDsEO2jFB6ZrNfHqryafV6i3dPQTDslBtS1/Aw4VDH zwLlt2XEUPE0JzfC9YpsrDv35Ta71ZRJ+n6T6xUbYYn54dPTvjCVInfqFmADLTa/1hgZ t2Mg== X-Gm-Message-State: AOJu0YzP3b004oE06tH7D1wSDMg6ndZxdvC0bQ8r0kHATJ4nJDU+oOHC V/gSy0ABXMnBFsdbJxP0eqDROJLektgswxX+UQMmI6XbKcW72O0lK5DnZJ0RlKfZJZO/Vd3c/8E lJMapYNtohw8C983iQPg= X-Received: by 2002:a17:906:730f:b0:a23:40c8:55ab with SMTP id di15-20020a170906730f00b00a2340c855abmr1809479ejc.21.1703069996123; Wed, 20 Dec 2023 02:59:56 -0800 (PST) X-Google-Smtp-Source: AGHT+IHN3YE5UPl7iD4rC1hUZHJWNg9UM2avS9kOOMEP2bGjCUpWm5kLb4QwH2Xub6L9W+cJmtHVig== X-Received: by 2002:a17:906:730f:b0:a23:40c8:55ab with SMTP id di15-20020a170906730f00b00a2340c855abmr1809474ejc.21.1703069995735; Wed, 20 Dec 2023 02:59:55 -0800 (PST) Received: from [192.168.0.129] (ip-94-112-227-180.bb.vodafone.cz. [94.112.227.180]) by smtp.gmail.com with ESMTPSA id ca15-20020a170906a3cf00b00a235b1e81b4sm3362110ejb.114.2023.12.20.02.59.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Dec 2023 02:59:55 -0800 (PST) Message-ID: <2bae9689-e638-262d-ad5f-6ae38c900ce0@redhat.com> Date: Wed, 20 Dec 2023 11:59:54 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: Shadow stack backtrace command name To: "Schimpe, Christina" , "gdb@sourceware.org" References: In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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: Guinevere Larsen via Gdb Reply-To: Guinevere Larsen Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" On 20/12/2023 10:42, Schimpe, Christina via Gdb wrote: > Hi all, > > I am writing to you to collect feedback for the name of a new command, we would > like to introduce. The command shall be used to print the shadow stack backtrace. > > 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. > > This is an example command name and output for the shadow stack backtrace: > ~~~~ > (gdb) info shadow-stack bt > Address Symbol > #0 0x0000000000401131 call1 > #1 0x0000000000401145 main > #2 0x00007ffff7c3fe70 __libc_start_call_main > #3 0x00007ffff7c3ff20 __libc_start_main_impl > (gdb) set print symbol-filename on > (gdb) info shadow-stack bt > Address Symbol > #0 0x0000000000401131 call1 at amd64-shstk.c:51 > #1 0x0000000000401145 main at amd64-shstk.c:56 > #2 0x00007ffff7c3fe70 __libc_start_call_main > #3 0x00007ffff7c3ff20 __libc_start_main_impl > (gdb) help info shadow-stack bt > info shadow-stack backtrace, info shadow-stack bt > Print the entire backtrace of shadow stack, > or the innermost [COUNT | -COUNT] addresses for the current process. > To print the source filename and line number in the backtrace, > the "symbol-filename" option of the print command should be toggled on. > (See "show print symbol-filename") > ~~~ Hi! My first thought about this output is that I don't think most users are interested in what goes on below the main function. I think it would be nice to suppress that output (I personally would like that to be the default, but as long as its an option I'm happy). As for names, I don't see a need for starting with "info". In my opinion, just calling it "shadow-stack backtrace" is fine. Users could then set their own abbreviations, like shstk or cet if they like. As for if the name should have 'backtrace', I think it would be good that if actual command has it, but then adding an abbreviation to just "shadow-stack" if backtrace is the only command associated with it, but I can see how that could be confusing for end users if we add a new command after one or more releases, so I'm not married to this idea. Some more thoughts below > > 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" > > From my perspective, the command name has the following pros and cons: > (+) Easy to understand by just looking at the command name. > (-) Rather long syntax > > We also considered other command names such as > > - "info cet bt", "info cet backtrace" > (+) Short syntax possible > (-) Not so easy to understand by just looking at the command name. I miss the > name "shadow stack". I don't like this one very much, because searching CET online won't give you much info, so a user would need to look at the help text to then figure out keywords to search to learn more. > > - "info shstk bt", "info shstk backtrace" > (+) Short syntax possible > (-) "shstk" ist not an official abbreviation (in contrast to "cet"). "shstk" is > mostly used by the linux kernel and might not be known by the user. I like this better because it is much easier to find what is going on, but as you said, users may not be familiar, so I still lean towards spelling out shadow-stack and letting users make their own abbreviations. > > - "info shstk", "info shadow-stack" > (+) short syntax possible > (-) Without "backtrace" in the name, it might not be so easy to understand. > > 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. I started really disliking this option, but the more I think about it, the more it sounds like a neutral one to me. sure, the output is much more basic, and many options/commands wont apply, but if the regular backtrace is failing due to some stack corruption or something, this feels like a more natural approach to solving that issue, which I imagine would be the most common use case for most users. That said, this is all speculations pulled from thin air, so feel free to ignore this last part. -- Cheers, Guinevere Larsen She/Her/Hers > > 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. > > Best Regards, > Christina > Intel Deutschland GmbH > Registered Address: Am Campeon 10, 85579 Neubiberg, Germany > Tel: +49 89 99 8853-0, www.intel.de > Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva > Chairperson of the Supervisory Board: Nicole Lau > Registered Office: Munich > Commercial Register: Amtsgericht Muenchen HRB 186928 >