From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id dkNzCz1djmbggiEAWB0awg (envelope-from ) for ; Wed, 10 Jul 2024 06:06:53 -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=rWU7+l5R; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 170701E0C3; Wed, 10 Jul 2024 06:06:53 -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 F26791E097 for ; Wed, 10 Jul 2024 06:06:50 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 643D43870C21 for ; Wed, 10 Jul 2024 10:06:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 643D43870C21 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1720606010; bh=yo80crrY7AOa+6O12jMbYMdErs+f7yaX2BvUL+PeZec=; 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=rWU7+l5RlZ0E7NKgsv8fFs0fKb5fsoLXcp8GU7Lg9QZyhbfNfrP7n81HZ6iWAoEie QU/wm1SJH4OiQMTetAbn2gU/fSHZulrb5M/EDUDbi55Es1N6J04TmYcUIb/fdPWhVA 5yZetJ5JxfF8tb5igtRc5I8KQgZUa2pA9Sk2PVcE= 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 B00A6385828B for ; Wed, 10 Jul 2024 10:06:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B00A6385828B ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B00A6385828B ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1720605972; cv=none; b=k1Vc4Wdyi4iUHCgm4S3EN++/ZL6XNx0xwR4SVwATZG9Ycdxnss+br0WlXI3Vw9J1SxcL5awHUuZYIkuE6d5wZvEkWTenNp9X+9OPGR+brT3dBj5SbSovZMCMiPlAygOSOYkC5tVsnWCJlFi/XqA3WzTmbbKTEsbV8WOIOvRLbL8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1720605972; c=relaxed/simple; bh=Zws8z3G211xceyXhG0VefNaJZSRgx1CxbP5yJi/fs5c=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=M5SfDQ2vsEH7gii2WWblaQEkO+UROZ2WQercTMUTqhpAJp81lY4FMT8N29sSmDOqayUB9q5h4u4a4q4Q59K0BCHyB/OB3KgpiG7iaYh6m3EyUVK1XFZOh6NT6xHq/Lby27A5hiyxim/f8APB6L9aA3Mp3KhYgNtjpmf0NOGGTV8= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from mx-prod-mc-03.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-636-sy4uSfSYO3WN6HCFcDwAtA-1; Wed, 10 Jul 2024 06:06:03 -0400 X-MC-Unique: sy4uSfSYO3WN6HCFcDwAtA-1 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (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-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 84D4119560B3; Wed, 10 Jul 2024 10:06:01 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.45.224.154]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 869381955F40; Wed, 10 Jul 2024 10:05:59 +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 "Wed, 10 Jul 2024 09:07:35 +0000") References: <87a5q0eq34.fsf@tromey.com> <871qb6c5y8.fsf@linaro.org> <874j93vh4w.fsf@oldenburg.str.redhat.com> <87bk36zjda.fsf@oldenburg.str.redhat.com> Date: Wed, 10 Jul 2024 12:05:55 +0200 Message-ID: <87y169h88s.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.17 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: > We are currently working on the implementation of the shadow stack backtrace. > This is how we would print a shadow stack backtrace for signals: > > ~~~ > (gdb) bt shadow > #0 0x00007ffff7c54d90 in __restore_rt from /lib64/libc.so.6 > #1 0x80007ffff79fffd8 > #2 0x00007ffff7c54ce6 in __GI_raise at ../sysdeps/posix/raise.c:27 > #3 0x000000000040115d in main at /tmp/amd64-shadow-stack-signal.c:32 > [...] > ~~~ > This would be the corresponding ordinary stack: > ~~~ > (gdb) bt > #0 handler (signo=10) at /tmp/amd64-shadow-stack-signal.c:25 > #1 > #2 __pthread_kill_implementation ([...]) at pthread_kill.c:44 > #3 0x00007ffff7ca15f3 in __pthread_kill_internal (signo=10, threadid=) at pthread_kill.c:78 > #4 0x00007ffff7c54ce6 in __GI_raise (sig=10) at ../sysdeps/posix/raise.c:26 > #5 0x000000000040115d in main () at /tmp/amd64-shadow-stack-signal.c:31 > ~~~ > Do you see much value in combining the outputs? The difference is that the shadow stack backtrace does not contain the interrupted instruction, so frame #2 in the traditional backtrace. This is more important for CPU-generated signals such as division by zero or invalid memory access, where you really want to see the fault address in the backtrace. > The elements on the shadow stack are following the description of the linux > kernel for signals: > "When a signal happens, the old pre-signal state is pushed on the stack. > When shadow stack is enabled, the shadow stack specific state is pushed > onto the shadow stack. Today this is only the old SSP (shadow stack pointer), > pushed in a special format with bit 63 set." > (https://docs.kernel.org/arch/x86/shstk.html) > > Frame 1 contains the old SSP with bit 63 set. I would like the kernel to push the address of the interrupted instruction as well, potentially with additional flag markup. Or maybe it's so early that we don't need it. The signal return path would have pop it off the stack and not validate it because I think it's an expected use case to redirect execution from a signal handler by patching the signal context. Alternatively, the kernel could push the address of the signal context, which might be even more useful. I think it would be useful if the shadow stack contained all the data needed to implement the glibc backtrace function, not because glibc is important, but because it seems to be a good indicator what programmers expect from a backtrace. We also need to figure out how this interacts with LAM. Does the CPU push tagged addresses onto the shadow stack? It could impact the type of tagging the kernel can use for its own special addresses. Thanks, Florian