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 B970AEB64DA for ; Wed, 5 Jul 2023 19:10:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 532968D0006; Wed, 5 Jul 2023 15:10:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4E2818D0001; Wed, 5 Jul 2023 15:10:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3AA338D0006; Wed, 5 Jul 2023 15:10:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 2C5FD8D0001 for ; Wed, 5 Jul 2023 15:10:53 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id EDA9DA0C18 for ; Wed, 5 Jul 2023 19:10:52 +0000 (UTC) X-FDA: 80978500344.07.620EBDF Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id 15BDB40019 for ; Wed, 5 Jul 2023 19:10:50 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rArXyDhG; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.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=1688584251; 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=imX+GMPQBkVIbLQsiTplKOnd6h6BQ1O2Gck/GOdLjAk=; b=yngab/IT0Qs/pONbOJiJzPnmqBJr/ULc3K9ILLFgJSNqOpPb6+I+qnQhKCBcLdH84Sua9V OVJCVUBHg1Y3r7jF82aLupur9UjhYIcZhka2a8Go1EmP2MmNPybbSdpmzcUAQeyeBLacf2 VzCUhGNCKxg7sWRFYtwBMl0DFOGFVN8= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=rArXyDhG; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf27.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=1688584251; a=rsa-sha256; cv=none; b=A4RT9D1TWi7BDbH8tpiPZaNmq+ppOl8dDAFZuUlShypvwYYRCVpZZ9dth89YJQbFh3Ks5E 6rzdIilWkkcSSZ1Qu6hj8Y8wV9aeE5m8qr1zR7mCI3IWnyyZ3qTCor63ENe3wLzJT1F0An jLwFvtrarS+I4QKeJMGkrxqOD/PH5YM= 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 2C8E2615E6; Wed, 5 Jul 2023 19:10:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1CF8FC433C7; Wed, 5 Jul 2023 19:10:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1688584249; bh=fa13Rrp/ewRaXb15ROYQwSY3HRGY9tgXoBGOXCxz7qQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=rArXyDhGF1qeLuF+8vWJDIK/3L3LjaPvhWozvBC873N6pi4MbeTwNwAiwB2VIO8h6 H1wZgqBv55CuKdgGKzBaOx1+aTzXj97ktJjjoYNYrnHUNlWeipg0mYZlwowYai1JCY pHd1zhhWKMbNZpkU1QRyUO0UFs24TGHkrcWXFOQO/3qDPNx1lcaErhu3E7ZSaV6zWQ fl80eJEGPWLHhYv4neHzkW7KlYXcejS+pjyFpgeI1wlvZED9d8Zoz1SrIqGuPbWjuF sCKJQYBvh+dsTB8CcTxnWyMgQobRcdSdt6ZzTMoOqxT247MLe8MwfcFtQzucR/H749 HI7K1Xf1aqnBA== Date: Wed, 5 Jul 2023 20:10:38 +0100 From: Mark Brown To: "Edgecombe, Rick P" Cc: "szabolcs.nagy@arm.com" , "Lutomirski, Andy" , "Xu, Pengfei" , "tglx@linutronix.de" , "kcc@google.com" , "linux-arch@vger.kernel.org" , "nadav.amit@gmail.com" , "kirill.shutemov@linux.intel.com" , "david@redhat.com" , "Schimpe, Christina" , "Torvalds, Linus" , "peterz@infradead.org" , "corbet@lwn.net" , "nd@arm.com" , "jannh@google.com" , "linux-kernel@vger.kernel.org" , "debug@rivosinc.com" , "pavel@ucw.cz" , "bp@alien8.de" , "rdunlap@infradead.org" , "linux-api@vger.kernel.org" , "rppt@kernel.org" , "jamorris@linux.microsoft.com" , "arnd@arndb.de" , "john.allen@amd.com" , "bsingharora@gmail.com" , "mike.kravetz@oracle.com" , "dethoma@microsoft.com" , "oleg@redhat.com" , "andrew.cooper3@citrix.com" , "keescook@chromium.org" , "gorcunov@gmail.com" , "fweimer@redhat.com" , "Yu, Yu-cheng" , "hpa@zytor.com" , "x86@kernel.org" , "mingo@redhat.com" , "hjl.tools@gmail.com" , "linux-mm@kvack.org" , "Syromiatnikov, Eugene" , "akpm@linux-foundation.org" , "Yang, Weijiang" , "dave.hansen@linux.intel.com" , "linux-doc@vger.kernel.org" , "Eranian, Stephane" Subject: Re: [PATCH v9 23/42] Documentation/x86: Add CET shadow stack description Message-ID: <2a30ac58-d970-45c3-87d2-55396c0a83f9@sirena.org.uk> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Dmr76OeBT4pTBUQM" Content-Disposition: inline In-Reply-To: X-Cookie: Don't feed the bats tonight. X-Rspamd-Queue-Id: 15BDB40019 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: k8iu8daz7sy6jigy6zdbfz5gspfs48am X-HE-Tag: 1688584250-952572 X-HE-Meta: U2FsdGVkX1/RkIe43kYyFNLWqLk60/dZ8SHDX9lSrNswj0h7SYgg/6GmauNI7rXsvCgyNHpMjDdEzQlMkEQwPC2pqx2/NFe/aGdGX5/xZ4Ko2BXM20pd2TSx1dTF3+yksrlMrB0/QPh9S1G8LDDub1JcivQYRxSUxcnHfKUVbnXr7Lx5Z/KecEDtNbA5FxK9zVuBiVMhmApHJSRVUe5xddjtpCPQ5Tv4xbAXxQYpn62PH15q5WKHuv6j6wmu7vxgO5SKAb91EuIldBV+BtPGxRUcQVc1QPP2a+KHa2PPAX7WkkDmp43fMyCbXn3WiSTToDAy5FW+0haHinCWQlI1Ix1m2EmxLGwrrF3K7FxHQSA4dzgFBomir0YO5S8P1timhYsFyom5xMUuxwFI8PltRXndBwmBaxJXBpwi3EwW8uU33gDOpzkKZSloHFPblR7Z3YZjwHkfDG+hXt3B25ULhlSq+vfoesBrs6r6VTyE6uIhsKm5th39+/R/C6MLTCPF51PlkxnFqMyEWWiIIxNLuZCqpxsM8tNeHIS3v/WB86uABQs8reUxL12swpnYAKIOgEI36UiSoSNUMh2DHSCsSkUZAsaZGHzAtg6xKMGHoKtiLUuysZ6+2yBVEQOQi1k1jBZC3gYy3z4TEuE+t2HWkuLgFRWSWg2QuzMYL13PpaEdBWL6YqhBPEmPsB8aCP/7wnpDMfQHkRpgIMd6bqvm7bamioxwVAZY4/HIKJs1NjLNnfrn73FH/zR/XIuyAIbKt3grdHpHXnw+W6OKQMoBZCThRLYdMi722M07RVDTjzuiKN3T4acyFwhsCq72JNkwkiOvXuLYAwCXGVdUIS5reFvQHVNau/9ACW//KGBAs5h56f5Q8RX9NpDL2HbN76f4ZUZBAuLjLHReigyaPGQhCGrtVFXwvsIMXazhVzsZlOLRzxklx2yveTYtEWCNfj8a9/6yp+HXrlSjdH8DU9p lzn4+RNy Tiz898UQkBfeP5m1hU0pXeDcODJdTHG9+aqz7UzvSlnNv4bHn+R1g3eM89pgu1yGV9mLhMONBjS0IS8RkCy8vDSRgR2DQvG9RT22ANMMPBKhLeihUFA8+1NDFzxSGHzvb8euqaRc8P2HWfPcKnjKkVRV9QzHduonoep8sHlTrGGOAIoz8MX1+M9R5wChc4plGYKbdJPf3qgsz3iH5MY5sn52RuxFcH0oLAPeXNTiUF3IVRmgDQiTHeZKtgqSHmCfdI3Smwv6D9WFzZWtVyHloxt9f/9/V1Vjuu4ZdKUX/z59/T8W9oQfMxoVOA1YBSkRx3FhWOTqdFEDA4Y90bz4URqj5WYM0pUoL3fK3na+7M6Et6k/ZixewhjSSVmJ/ZDtdeDf7qkYNBMudOoULuzyZ6ZBqMXMi1GDbqhmta4+cnBYkC3I= 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: --Dmr76OeBT4pTBUQM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Jul 05, 2023 at 06:45:38PM +0000, Edgecombe, Rick P wrote: > Looking at the docs Mark linked (thanks!), ARM has generic GCS PUSH and > POP shadow stack instructions? Can ARM just push a restore token at > setjmp time, like I was trying to figure out earlier with a push token > arch_prctl? It would be good to understand how ARM is going to > implement this with these differences in what is allowed by the HW. > If there are differences in how locked down/functional the hardware > implementations are, and if we want to have some unified set of rules > for apps, there will need to some give and take. The x86 approach was > mostly to not support all behaviors and ask apps to either change or > not enable shadow stacks. We don't want one architecture to have to do > a bunch of strange things, but we also don't want one to lose some key > end user value. GCS is all or nothing, either the hardware supports GCS or it doesn't. There are finer grained hypervisor traps (see HFGxTR_EL2 in the system registers) but they aren't intended to be used to disable partial functionality and there's a strong chance we'd just disable the feature in the face of such usage. The kernel does have the option to control which functionality is exposed to userspace, in particular we have separate controls for use of the GCS, the push/pop instructions and the store instructions (similarly to the control x86 has for WRSS). Similarly to the handling of WRSS in your series my patches allow userspace to choose which of these features are enabled. --Dmr76OeBT4pTBUQM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmSlwC0ACgkQJNaLcl1U h9DuvAf+JgrHCBe/TIeWaTXbh1FnwnOIdz2doyUlgUqzu5K5fGjE+AF6nytAvxsw HIFAEaZItokV1L7RHKWjunwM1sjA7UmdGfhH1i5KYZF8XpmfgZTK3ZiaHJO8EKsL WAN1sgXlNOkCfoE0vggDqr9ksQ5WGjJS3TDgoXnTQna75/J3ggrKWQPdBRZ52/YK Swo9HHZ/aUSvO8Xo6iSEetZIyxUjcDvPVGBNrMauABpExP1ww/LA7NeJIUF8O32/ ZYRWOy09jbfMJA80DH+bfaHVJw/g9ZI65/tBFI364wcp4LXSiymoz6f3yQUyBJV4 97UBNALINVmtmDPEpmSVX6DM3PbVWA== =HVOg -----END PGP SIGNATURE----- --Dmr76OeBT4pTBUQM--