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 C7594EB64D9 for ; Thu, 6 Jul 2023 19:03:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4540F8D0001; Thu, 6 Jul 2023 15:03:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4033A6B0074; Thu, 6 Jul 2023 15:03:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2A3958D0001; Thu, 6 Jul 2023 15:03:38 -0400 (EDT) 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 175C56B0072 for ; Thu, 6 Jul 2023 15:03:38 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DA7E9AFE65 for ; Thu, 6 Jul 2023 19:03:37 +0000 (UTC) X-FDA: 80982110874.29.B21D9EF Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf01.hostedemail.com (Postfix) with ESMTP id C2E5A40012 for ; Thu, 6 Jul 2023 19:03:35 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="l49iNd/E"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688670215; a=rsa-sha256; cv=none; b=RWy7tXh0YJGZ/F4suq1FudumdJ/ubZ6oRzyxzYQ80FrL+eJV9wZeZ6CYYmlFFppHIpUEFB mxdzKUolJzIhoAZdllMQGpgv0liHl4fGkHqY+wub1jgbcp9zpIOhIFL+2TjJvuFRJLSk6h v9DlSt1drZbGh9NzUE8QjKTH3nhQj/0= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="l49iNd/E"; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf01.hostedemail.com: domain of broonie@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=broonie@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688670215; 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=EnRuWugoAVFHpsRXEAhlMgRT54VeIKT0ZrLoAJwWxds=; b=vxNbS9hvxcKeL3cHDyyKv/sp06g2gsAYsHZudeZzlzYObRsJrytT299eADmfUPta63ZJeC WaeevkNumtFTVsbDp3FZDMgbbjBf3LbBh3hq7P172Ll0Y4hXU+DLdRD9b8jEy8k3XUnaPX SjInI9t2dweIH3XFHKv9yPb9LPOrO8c= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8E18F610A4; Thu, 6 Jul 2023 19:03:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 544ECC433C8; Thu, 6 Jul 2023 19:03:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688670214; bh=zcBaqYahXAhcJ/QGg28GedoZoIVRedEm6esUTbPIAu0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=l49iNd/Eq8MI5J5iGM4+8yyNRvSI7FDdHtcqmzr+ZqirbMTsIw7q3Q5ls0sGRQ1yg z12VRI0ksavt/91yuHf0jyduqbFage5sdzXAiUCfc8JooCD+FT8ZrR2fw8/+jIig98 xd8nda7Xkyt7AKcS/hSVbzvjQxrKe8VVfP1cKqTmILol4DBbfnnJ7UFvCYEZ7E5laC qlPdgNIB8qOVEOwzDR9a83fNXrlEFe4WNgZhRGiYa2tbLy+64yYabP1ekBXbKoOa15 tdj8edsHQRhdln8WejySsXzZQZSp+iGneoUFwGeXn98WHx1IhiyBrFyDzHYtL9S/M3 z6TIB6xsj2z4w== Date: Thu, 6 Jul 2023 20:03:22 +0100 From: Mark Brown To: "Edgecombe, Rick P" Cc: "szabolcs.nagy@arm.com" , "Xu, Pengfei" , "tglx@linutronix.de" , "linux-arch@vger.kernel.org" , "kcc@google.com" , "Lutomirski, Andy" , "nadav.amit@gmail.com" , "kirill.shutemov@linux.intel.com" , "david@redhat.com" , "Schimpe, Christina" , "Yang, Weijiang" , "peterz@infradead.org" , "corbet@lwn.net" , "nd@arm.com" , "dethoma@microsoft.com" , "jannh@google.com" , "linux-kernel@vger.kernel.org" , "debug@rivosinc.com" , "pavel@ucw.cz" , "bp@alien8.de" , "mike.kravetz@oracle.com" , "linux-api@vger.kernel.org" , "rppt@kernel.org" , "jamorris@linux.microsoft.com" , "arnd@arndb.de" , "john.allen@amd.com" , "rdunlap@infradead.org" , "x86@kernel.org" , "oleg@redhat.com" , "andrew.cooper3@citrix.com" , "keescook@chromium.org" , "bsingharora@gmail.com" , "gorcunov@gmail.com" , "Yu, Yu-cheng" , "fweimer@redhat.com" , "hpa@zytor.com" , "mingo@redhat.com" , "hjl.tools@gmail.com" , "linux-mm@kvack.org" , "Syromiatnikov, Eugene" , "linux-doc@vger.kernel.org" , "Torvalds, Linus" , "dave.hansen@linux.intel.com" , "akpm@linux-foundation.org" , "Eranian, Stephane" Subject: Re: [PATCH v9 23/42] Documentation/x86: Add CET shadow stack description Message-ID: <352b0dfa-9da1-4996-8086-b45950f023ff@sirena.org.uk> References: <2a30ac58-d970-45c3-87d2-55396c0a83f9@sirena.org.uk> <0a9ade13b989ea881fd43fabbe5de1d248cf4218.camel@intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sGlMqBUxl5KKZAGa" Content-Disposition: inline In-Reply-To: X-Cookie: Don't read everything you believe. X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: C2E5A40012 X-Stat-Signature: 4kwune3zggsqnfw95pxddd31jdbjin47 X-HE-Tag: 1688670215-557285 X-HE-Meta: U2FsdGVkX1/tRcynO2tbNyexrXT9vfCAGR2VMIpseJ9ljswkDC2ojBWA1mlxVJSjihPEJLEZ6bbwDgVcHIQEDz8DRIFWtHj93c3lj7L3VX9oG6NU6kXSc3pwc/fH/c5FI4GB20KlRuyhA4P5TMFs+y9kTOwiAgcnJFGqANFXyZLMF07fTldZqM6Vivw6XVwvIiVIErQpSYIHwC8eoDTZiePkv6RuM8DzLL7qITtSQ/LRqZRsucGgKDOGPGOtGKi0XGC8VG/lxt9R5e42Eq+tk8I4kszMX38wWODqhifVddd07mzq4XNo+B0+qMkV4WMbk10bQ0hmAUNlvqCErifEN4ob45xW87dwCGd4LuWrH/yxfXqHnaraDlRzvW6th50EG/OYSjoJt6bOoTIi6krTahNt0HNg33/OHqYrwE3+Oa456udTr1QtFXErA9hh999vTNWNwY+mg2I1gHbP+ut4nbkcZkQ8fRanEoMYkryhVzV8BfsJU1bXtbeo2zHbI7BP38NLpuOHRgeJnAoJOeLwaRa4pwVrmkv6rjMOY/0MHpuFQpq1THa1UwUdu33+OUQQqSL7d2gxs0plgg+UvWpN8NvKMDv/ajFciTCYTFtYkCMUZ58c/prDqhm1xKXz0IrXcyDotCjD34GjAPL1GNU2Iq+EMForbphDZMuQ+KNq1Ar1G3SePopugkooolsl02v3YZ5reVPP27tjcmwQPno8uoWDErBmAVMr5qC9XA5PM87z0lPk7FGTifWkx5+mSvsLuJPh8WMZ5zxut5GA2c8G36NWWIJt8Y+y0qdQPYodcRMPy1mSF86srmXlVI4XGSob1ePOo4LEwMlraVUZ9EIFajBuryFLLx9uBLYWiqQvRuceTXqrVjlTJ0DXmFR4XNR6onqh0TYQezCFhdex47vDicN7LSDSGkEeor84ycHMj4E1vli5arjTLUxiR+rQrXMq5DakjmYTf/SJ+EKvkGJ vRwh8Ung BcIAviJcDoM9UJ9iilo43xowBx6GftemdO7RlHZJ+cIGKlvMVKept6CO3H8/0bVwX6If6YLzhL8q8Nvg6HkpQd/hvnxhY0YqfqvHiFKSjNZOQO/VvMqYh5ffgnez/nzbu9rXIj/J3jBEP8Eet/HGGGFNGO2gsuO4U+Js7q1OE4DilnBhHMUCVldqg1WUERTSk6uQq9T8xXm4+VSq1vuEaq6kRiec1ET5Hiyt2BCF+vTJvte05CIg6oulRUOuTqjzlTFFSfTJhirDjfk9v0H0gKlJrQcc9IaboAQiH4ekzMSj8x/ixg5wNmc7tddIX+X3XXtkR2XFmStaldgypSAq3fZYxXdEMvE4vJQ5OTbtxutSpLUqBkdSK1GRVBDwG3qz6kGBNEspbWnAy+ESn4alg0yY6C/BTOehfigXhg8YxweKrwDAh76Sb0QA6PC1pjOlT0Q1LMEikfWVuTe+FZbSZANkqTBj5EPw9hakm9ABlfQdc/FXACav3KAMuGssmO3324AaqND2VSyRcoqQ= 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: --sGlMqBUxl5KKZAGa Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 06, 2023 at 04:59:45PM +0000, Edgecombe, Rick P wrote: > On Thu, 2023-07-06 at 15:24 +0100, Mark Brown wrote: > > szabolcs.nagy@arm.com=A0wrote: > > > The 07/05/2023 20:29, Mark Brown wrote: > > > gcspopm is always available (esentially *ssp++, this is used > > > for longjmp). > > Ah, sorry - I misremembered there.=A0 You're right, it's only push that > > we > > have control over. FWIW the confusion there was some of the hypervisor features which do tie some of the push and pop instructions together. > Ah, ok! So if you are not planning to enable the push mode then the > features are pretty well aligned, except: > - On x86 it is possible to switch stacks without leaving a token=A0 > behind. > - The GCSPOPM/INCSSP looping may require longer loops on ARM=A0 > because it only pops one at at time. > If you are not going to use GCSPUSHM by default, then I think we > *should* be able to have some unified set of rules for developers for > glibc behaviors at least. Yes, the only case where I am aware of conciously diverging in any substantial way is that we do not free the GCS when GCS is disabled by userspace, we just disable the updates and checks, and reenabling after disabling is not supported. We have demand for disabling at runtime so we want to keep the stack around for things like a running unwinder but we don't see a practical use for reenabling so didn't worry about figuring out what would make sense for userspace. glibc isn't going to be using that though. --sGlMqBUxl5KKZAGa Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmSnD/kACgkQJNaLcl1U h9BAuQf/ZlxwHanBD/TEBQkEI5Myy6kEtI1p6LWXwsCmree4AOmHNPxc7m9HqdSD d+N1YrfV4XPVTnR5xnknnbKZ1QGdOvKAhv0UbDFFRJn/TY3d8miPOMqgpAF35K6C Urpa0SPngTHYCZ32LKoHyy1G9zG4nH5FgXcN0bmOzU8+orrnvzjXAUbroEbgUxQR Af3rlLZN1E1qKzBIU7LC3+InmYpYeWOU3K7B/XP6c/OQMJrJr4k4gWN+DW7bQMsF SkmwVwADaxUidhKpXFWwvQ4bsBo3x1Es7j7wjU8uFOwX+gxAwTqgWkZBjg8D79Om pXGXRkbF+a5wHjTTpEGJRnqCBBqQxw== =cL31 -----END PGP SIGNATURE----- --sGlMqBUxl5KKZAGa--