Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E26B8C678D4 for ; Mon, 6 Mar 2023 16:39:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230043AbjCFQis (ORCPT ); Mon, 6 Mar 2023 11:38:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47354 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230028AbjCFQhD (ORCPT ); Mon, 6 Mar 2023 11:37:03 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1640B410A9 for ; Mon, 6 Mar 2023 08:35:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1678120504; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=8gChhWa5+pV9cvva7KKeCwxEw+kt5hxoG0ztKCrLbRE=; b=Ecxh7HjTlmpjSP+r2T058X2l2otz6koqr/ebem0PJ9W/B8NsVyUllFRfbci2yjsTOSLf9a HlXF4K9ITZe6jSzY3XaK9morIxklujf1VDYsaLlqWkjXK6fALpolimN4OvYHOlWu0SSA56 rIozv5FPI1tFEAHDN8H8pjBThvWSLPA= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-479-xAeRr96XNX6SiROa8aY1Yg-1; Mon, 06 Mar 2023 11:31:52 -0500 X-MC-Unique: xAeRr96XNX6SiROa8aY1Yg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 583BE3850545; Mon, 6 Mar 2023 16:31:50 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.80]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 62FB140C10FA; Mon, 6 Mar 2023 16:31:42 +0000 (UTC) From: Florian Weimer To: szabolcs.nagy@arm.com Cc: "Edgecombe, Rick P" , "david@redhat.com" , "bsingharora@gmail.com" , "hpa@zytor.com" , "Syromiatnikov, Eugene" , "peterz@infradead.org" , "rdunlap@infradead.org" , "keescook@chromium.org" , "Eranian, Stephane" , "kirill.shutemov@linux.intel.com" , "dave.hansen@linux.intel.com" , "linux-mm@kvack.org" , "nadav.amit@gmail.com" , "jannh@google.com" , "dethoma@microsoft.com" , "broonie@kernel.org" , "kcc@google.com" , "linux-arch@vger.kernel.org" , "bp@alien8.de" , "oleg@redhat.com" , "hjl.tools@gmail.com" , "Yang, Weijiang" , "Lutomirski, Andy" , "pavel@ucw.cz" , "arnd@arndb.de" , "tglx@linutronix.de" , "Schimpe, Christina" , "mike.kravetz@oracle.com" , "x86@kernel.org" , "linux-doc@vger.kernel.org" , "debug@rivosinc.com" , "jamorris@linux.microsoft.com" , "john.allen@amd.com" , "rppt@kernel.org" , "andrew.cooper3@citrix.com" , "mingo@redhat.com" , "corbet@lwn.net" , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" , "gorcunov@gmail.com" , "akpm@linux-foundation.org" , "Yu, Yu-cheng" , "nd@arm.com" Subject: Re: [PATCH v7 01/41] Documentation/x86: Add CET shadow stack description References: <636de4a28a42a082f182e940fbd8e63ea23895cc.camel@intel.com> <9714f724b53b04fdf69302c6850885f5dfbf3af5.camel@intel.com> Date: Mon, 06 Mar 2023 17:31:40 +0100 In-Reply-To: (szabolcs's message of "Mon, 6 Mar 2023 16:20:56 +0000") Message-ID: <87wn3tsuxf.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * szabolcs: > syscall overhead in case of frequent stack trace collection can be > avoided by caching (in tls) when ssp falls within the thread shadow > stack bounds. otherwise caching does not work as the shadow stack may > be reused (alt shadow stack or ucontext case). Do we need to perform the system call at each page boundary only? That should reduce overhead to the degree that it should not matter. > unfortunately i don't know if syscall overhead is actually a problem > (probably not) or if backtrace across signal handlers need to work > with alt shadow stack (i guess it should work for crash reporting). Ideally, we would implement the backtrace function (in glibc) as just a shadow stack copy. But this needs to follow the chain of alternate stacks, and it may also need some form of markup for signal handler frames (which need program counter adjustment to reflect that a *non-signal* frame is conceptually nested within the previous instruction, and not the function the return address points to). But I think we can add support for this incrementally. I assume there is no desire at all on the kernel side that sigaltstack transparently allocates the shadow stack? Because there is no deallocation function today for sigaltstack? Thanks, Florian