From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5A682386181B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1703069999; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZXMq0NnEM9WWW8jE34mZ4jqngXTgmm//X8ZfqLe09O4=; b=dvFNKckgrkTWeFQAHLK4N+YGVaO1mrfjmXEzR0aD9m6dH7ViVhaxEMzzeciFrZX7zmgLLY kcFh+4KmG3juz0HxvRywlFL4XlklkWcjprgsYb6cgryNSezMAGCAeZTRk63TtI1JHuPyBP OaGnAMFXZaFQbstDIxrhlGeWniHxxgo= 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: From: Guinevere Larsen 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 List-Id: 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 >