From mboxrd@z Thu Jan 1 00:00:00 1970 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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5BA2CC64EC4 for ; Mon, 6 Mar 2023 16:31:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AECA06B0071; Mon, 6 Mar 2023 11:31:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A9C766B0072; Mon, 6 Mar 2023 11:31:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91754280001; Mon, 6 Mar 2023 11:31:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 813246B0071 for ; Mon, 6 Mar 2023 11:31:58 -0500 (EST) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 378CF1201FF for ; Mon, 6 Mar 2023 16:31:58 +0000 (UTC) X-FDA: 80539015116.21.9943D75 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf05.hostedemail.com (Postfix) with ESMTP id DA00C10000C for ; Mon, 6 Mar 2023 16:31:54 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="F/fgEc8S"; spf=pass (imf05.hostedemail.com: domain of fweimer@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=fweimer@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678120314; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=8gChhWa5+pV9cvva7KKeCwxEw+kt5hxoG0ztKCrLbRE=; b=M6CEXqOkq8/Pp8+wvigzIQ3ZE5v77+7s8d37sgiEbK1HOmVlo/wPEvpedHsA4CmCGKPwKp uKbj8G1Vsko6bC52cFBL0DFl6BIeOzftfR0i65WUsNIeK39rh0X+Iz1cOTwT2a7O/ZKs9c g6tXFmZyKSBqfE15kq4QoyaLErOFagY= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="F/fgEc8S"; spf=pass (imf05.hostedemail.com: domain of fweimer@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=fweimer@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678120314; a=rsa-sha256; cv=none; b=cWAMWDzRHrssxZbrJluJ7uRXVYQvL4sCDzoc6iuQsZqWaMJJk6FPmAhfLKczrrNreHr7NB aBCNb96c3WxgXmRBR+0Pp1kQUFN5lyMr8nqBjNxNqzxdhGXp/conJzmno2c4uofkZ5yxJ8 3TxOxIcPLi1fhPoQuLa5l8WxY1OjLp0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1678120314; 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=F/fgEc8SwnhXTwkhu4NdwKaQ/Z63If+D/f3ZLFBF+jguYbpz1CXjlh26GnLV4LoV4Vs4R5 dZLeFkj2Lh16sUWimtT80QwfmGT66SGeMXRLkRrendWusno1gYZimU10rwJN9cEO8dPezc eDhPjmOElkwJar7KnwiTdx1iMRWzcyI= 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 X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: DA00C10000C X-Stat-Signature: 58ugakkr9xcqnnxijyaua67m7eopbhsc X-Rspam-User: X-HE-Tag: 1678120314-917106 X-HE-Meta: U2FsdGVkX1+V8NrlAPrh7WkuyibNRv4ZaI/rqcJ75/1p1AwIl0KY3m9dSaI3Jmv1cQ/OSRJX4gd6y+/t73WGRhIR17mCVAMcCTb6ltHt6ddlXMjvUAqFOHH9wrwaciEkvM+kOoGBOP32uyYSdP+5vHI+ekI1F7Zo8rf3O9Uf1wjPkFMUUbnBGx042538sQd6vf4Ezpy8w5yHz1UzIWv1ZxpikrFUwTQlTWfpqcq4GOFt2nM0OdPAjhgtCkYfDqL9O2oserQjTuPM6aIZ5vnqL50ZXHc2oPe7DeLC8lECNiMSBUO4yricMKSOKotjgWEROSwrX1/Ej0LRowuzjdcsPUlZ5NvSVoUHM4HMbBTF0raqCr3e6HoaHcGGTlfiraG7sok6i+Z8lHCvEvcbyICRyRn03yNDl7s8XDTif9RCnnwqhfK/oQ88By9k2Ro8fY+xMZarWKCXjJ5wnwJabfG/33MDLWakw5dThX0h1S0UuVz6QyYR62bBxBBxhGpNoHzb5I6uQ/SmIpuUlLUB0H8FDWmsesbzCVmZVAHexeuOL8iwBPytEoVJiVCVRJNAznNdKxeWgzI+j2couY0YdLvUQzrfnauGa4APftS2esNiMJz7mYrKYlrKbzdMjicakP+32BpoZ5aNX+LGk66pxKxATdjwDdueYLIfJYbDGgSh4tecCUQu4RPoF7xOzm/woVyuV+E7tGokikHhLTt3GtbLvjT93qL/+WjjifTW8RMSqKREuhJ76h0b0Sks66axIeYU7Eet6thh/ZH1eYEavSW0ajovJGMfkw2S6T+fhru8N4v+MwARvrwCLwiDkoTO8N8yuFCiVgSwlnGQK/LLrbujU5QCm88l2U1p5W29P9IeYA/rCmWL6p90ekG5fZdMKFFtDhah1YE6OlsjxOAlc40gNetlqVbO9d6p6ye4v36BrXPVP+WVBlM2xYoMhz3O7TGG3Yp5WnU03Apqy43ywyf blrfAalg +Vy0+eRPGJnyFEO71KQOEh//B34wDs+BL/TyMKQ3i8YN/nMIhRiaYJGimDZOQtxTK9ekJfmpv1NrvblTryFlrqXBGfCHjMrB/z+bbqnihFafsVANhkOMQHwQhit3+CifQBlg5S3jHXWyEZCAtxiUxLwIH1Ai2RbGJqAbujECWhvqdjWmdErJ18/1VA+KXUHBsAZ4OgAzRQ1JiKgajYIA3CEHSzD4bRzZ7FmwuIPXqmk8Lwe6qwefqPju57w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: * 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