From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 34aAMGNUjWZbuSAAWB0awg (envelope-from ) for ; Tue, 09 Jul 2024 11:16:51 -0400 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=sLXDNVKI; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id AFCEE1E0C3; Tue, 9 Jul 2024 11:16:51 -0400 (EDT) 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 9BEC51E097 for ; Tue, 9 Jul 2024 11:16:49 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 0A7EB386D617 for ; Tue, 9 Jul 2024 15:16:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0A7EB386D617 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1720538209; bh=OpcnU3qRTCDgfuTxxmoklHNMkV0N7GbuM2L9e33Ok0A=; h=To:Cc:Subject:In-Reply-To:References:Date:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=sLXDNVKIBCn84dugUOovoYw04LBoXiFhTOBt3rdC7Xql0Rex6nNbUeeRyT3Qoi7cN NShPy+k2ZHYb83D244vkESjB+ppP2nVvxJmioJBb71xi7a8qiK0xYHQOCDNQBXyfrR 4vZsAi+ZTCIj9iRBdRImP/pQ0ycV2tdtLBA3Cey8= 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 2EFF9386182A for ; Tue, 9 Jul 2024 15:16:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2EFF9386182A ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2EFF9386182A ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1720538170; cv=none; b=ml+o+s66cr7J9QasL6oNcOREaxLJdy5kBi1ZBiUz4vvOng+1KOSvCku1NR1/6u1g95tMbg3MWx+uHXgIXAtRi547PNVtCE14H/uYP7gPHrR2muZwkYyqvTZIXlHgdPJeYED0QBNQ74qqDohaORRkQ0bhRKJrPSBd9RCf0gqKhGY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1720538170; c=relaxed/simple; bh=MEaP62Po6gSWuqJw4o7XpLOQbHEbA78ZtqanQdQsM1M=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=jwVc1QkWL0JPmzHiDf2ENadwTUXhGLkD8MIFtNNefJYZ6LMIx/vpXOoYcNln/ko9VuOSoDTdi1IoREAVpVqBFcv8o+Y8kxC/PmGyt66sBNR7LBVbL6EtNJYX8tojezj+EaewF7qZxQRmpqjU5fPpcayyLeZRiS2uvYLsgSc5fCE= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-634-PbkvP6HTO7ulUVblL8YnmQ-1; Tue, 09 Jul 2024 11:16:07 -0400 X-MC-Unique: PbkvP6HTO7ulUVblL8YnmQ-1 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DC7D51955F45; Tue, 9 Jul 2024 15:16:05 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.45.224.64]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5EAE31954219; Tue, 9 Jul 2024 15:16:04 +0000 (UTC) To: "Schimpe, Christina" Cc: "Schimpe, Christina via Gdb" , Thiago Jung Bauermann , Tom Tromey Subject: Re: Shadow stack backtrace command name In-Reply-To: (Christina Schimpe's message of "Tue, 9 Jul 2024 14:50:28 +0000") References: <87a5q0eq34.fsf@tromey.com> <871qb6c5y8.fsf@linaro.org> <874j93vh4w.fsf@oldenburg.str.redhat.com> Date: Tue, 09 Jul 2024 17:16:01 +0200 Message-ID: <87bk36zjda.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP 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: Florian Weimer via Gdb Reply-To: Florian Weimer Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" * Christina Schimpe: >> * Christina via Gdb Schimpe: >> >> > However, based on the use cases that I am aware of, I am not sure if >> > the user wants to always see the shadow stack bt in the ordinary bt >> > output (if shadow stack is enabled). >> >> Based on my experiments, Linux currently does not push the instruction >> pointer onto the shadow stack if code is interrupted by a signal. It still works >> because the return mechanism is different. This would be a very visible >> difference between ordinary backtraces and shadow stack based backtraces. >> As far as I understand it, the kernel could change, and it may still be early >> enough to make this change. > > Could you explain a bit why and what you think the kernel will change ? I could imagine that an additional address is pushed onto the shadow stack when a signal is delivered, so that we can get a full backtrace across signal returns. > Just to be sure that I understand correctly: > Do you think that this different display for the ordinary and shadow > stack bt in case of signals is one argument more for displaying the > stacks together? How would this look like? Currently, it's not possible to use shadow stacks for backtraces because you won't be able to print the location after line. At least that's what I encountered when I tried to use shadow stack for implementing the glibc backtrace function. > You can run "info proc status" and check for "shstk" in > x86_Thread_features, see https://docs.kernel.org/arch/x86/shstk.html. Thanks, that's a bit better than this (for SHSTK enabled): (gdb) print (*(tcbhead_t *)$fs_base)->feature_1 $1 = 2 Florian